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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to systems and protocols 
supporting transactions among diverse clients coupled to a 
network; and more particularly to systems and protocols 
supporting commercial transactions among platforms hav- 
ing variant architectures. 

2. Description of Related Art 

The Internet and other communications networks provide 
avenues for communication among people and computer 
platforms which are being used for a wide variety of 
transactions, including commercial transactions in which 
participants buy and sell goods and services. Many efforts 
are underway to facilitate commercial transactions on the 
Internet. However, with many competing standards, in order 
to execute a transaction, the parties to the transaction must 
agree in advance on the protocols to be utilized, and often 
require custom integration of the platform architectures to 
support such transactions. Commercial processes internal to 
a particular node not compatible with agreed upon 
standards, may require substantial rework for integration 
with other nodes. Furthermore, as a company commits to 
one standard or the other, the company becomes locked-in to 
a given standardized group of transacting parties, to the 
exclusion of others. 

A good overview of the challenges met by Internet 
commerce development is provided in Tenenbaum, et aL, 
"Eco System: An Internet Commerce Architecture", 
Computer, May 1997, pp. 48-55. 

To open commercial transactions on the Internet, stan- 
dardization of architectural frameworks is desired. Platforms 
developed to support such commercial frameworks include 
IBM Commerce Point, Microsoft Internet Commerce 
Framework, Netscape ONE (Open Network Environment), 
Oracle NCA (Network Computing Architecture), and Sun/ 
JAVASoft JECF (JAVA Electronic Commerce Framework). 

In addition to these proprietary frameworks, program- 
ming techniques, such as common distributed object model 
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based on CORBA HOP (Common Object Request Broker 
Architecture Internet ORB Protocol), are being pursued. Use 
of the common distributed object model is intended to 
simplify the migration of enterprise systems to systems 

5 which can inter-operate at the business application level for 
electronic commerce. However, a consumer or business 
using one framework is unable to execute transactions on a 
different framework. This limits the growth of electronic 
commerce systems. 

10 Companies implementing one framework will have an 
application programming interface API which is different 
than the API's supporting other frameworks. Thus, it is very 
difficult for companies to access each others business 
services, without requiring adoption of common business 

15 system interfaces. The development of such business system 
interfaces at the API level requires significant cooperation 
amongst the parties which is often impractical. 

Accordingly, it is desirable to provide a framework which 
facilitates interaction amongst diverse platforms in a com- 

20 munication network. Such system should facilitate sponta- 
neous commerce between trading partners without custom 
integration or prior agreement on industry wide standards. 
Further, such systems should encourage incremental path to 
business automation, to eliminate much of the time, cost and 

25 risks of traditional systems integration. 

Overall, it is desirable to provide an electronic commerce 
system that replaces the closed trading partner networks 
based on proprietary standards with open markets. 

30 SUMMARY OF THE INVENTION 

The present invention offers an infrastructure for connect- 
ing businesses with customers, suppliers and trading part- 
ners. Under the infrastructure of the present invention, 

35 companies exchange information and services using self- 
defining, machine-readable documents, such as XML 
(Extensible Markup Language) based documents, that can 
be easily understood amongst the partners. Documents 
which describe the documents to be exchanged, called 

40 business interface definitions BIDs herein, are posted on the 
Internet, or otherwise communicated to members of the 
network. The business interface definitions tell potential 
trading partners the services the company offers and the 
documents to use when communicating with such services. 

45 Thus, a typical business interface definition allows a cus- 
tomer to place an order by submitting a purchase order, 
compliant with a document definition published in the BID 
of a party to receive the purchase order. A supplier is allowed 
to check availability by downloading an inventory status 

50 report compliant with a document definition published in the 
BID of a business system managing inventory data. Use of 
predefined, machine-readable business documents provides 
a more intuitive and flexible way to access enterprise 
applications. 

55 A node in the commerce network establishes an interface 
for transactions according to the present invention that 
comprises a machine -readable specification of an interface, 
along with a machine-readable data structure that includes 
interpretation information for the machine-readable specif! - 

60 cation of the interface. The machine-readable specification 
of the interface includes a definition of an input document 
and a definition of an output document, that are accepted and 
produced by transaction processes for which the node acts as 
an interface. The definitions of the input and output docu- 

65 ments comprise respective descriptions of sets of storage 
units and logical structures for sets of storage units, such as 
according to a standard XML based document. The 
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machine -readable data structure that includes interpretation 
information according to various aspects of the invention 
includes data type specifications (e.g. string, array, etc.) for 
logical structures in the definitions of the input and output 
documents, content models (e.g. lists of possible values) for 
logical structures and/or data structures that map predefined 
sets of storage units for a particular logic structure to 
respective entries in a list in order to provide a semantic 
definition of logical structures (e.g. mapping codes to prod- 
uct names). 

According to other aspects of the invention, the interface 
includes a repository in memory accessible by at least one 
node in the network that stores a library of logic structures 
and interpretation information for the logic structures. The 
repository can be extended to include a library of definitions 
of input and output documents, a library of specifications of 
interfaces, and a library of specifications for participant 
interface nodes in the network. 

Thus, a participant in the transaction framework of the 
present invention executes transactions amongst nodes in a 
network that includes a plurality of nodes executing pro- 
cesses involved in the transactions. The method includes 
storing a machine-readable specification of an interface for 
a transaction, the specification includes a definition of an 
input document and a definition of an output document. The 
definition of the input and output documents comprise 
respective descriptions of sets of storage units and logical 
structures for the sets of storage units. In a preferred system, 
the definitions are expressed in a manner compliant with a 
standard XML document type definition DTD, extended by 
semantic mapping, content modeling and data typing of 
some elements. The participant in the transaction receives 
data comprising a document through a communication net- 
work. The participant parses the document according to the 
specification stored for a transaction to identify an input 
document for the transaction. After parsing the document, at 
least a portion of the input document is provided in a 
machine-readable format to a transaction process which 
produces an output. An output document is formed com- 
prising the output of the transaction process, based on the 
definition of an output document in the stored specification. 
The output document is transmitted on the communication 
network, typically back to the source of the input document, 
or elsewhere as suits the needs of a particular type of 
transaction. 

Thus the business interface definition bridges the gap 
between the documents specified for example according to 
XML and the programs which execute on the front end of the 
transaction processing services at particular nodes. Such 
front ends are implemented for example by JAVA virtual 
machines, or by other common architectures providing for 
interconnection of systems across a network. The business 
interface definition provides a technique by which a trans- 
action protocol is programmed using the business interface 
definition document. The program for the protocol of the 
transaction is established by a detailed formal specification 
of a document type. 

The machine-readable specification of the interface of the 
transaction is made accessible to other platforms in the 
network. Participant platforms include resources to design 
input documents and output documents according to the 
transaction interface specified at a complementary node. 
Thus, participant nodes include resources to access the 
definition of an input document for the complementary 
interface and a definition of an output document for the 
complementary interface. The stored specification for the 
accessing participant node is established by including at 
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least part of the definition of the output document of the 
complementary interface in the definition of the input docu- 
ment of the interface stored in the specification. 

The process of establishing the stored specification of an 

5 interface according to another aspect of the invention 
includes accessing elements of the machine -readable speci- 
fication from a repository. The repository stores a library of 
logic structures, content models, and schematic maps for 
logic structures, and definition of documents that comprise 

10 logic structures used to build interface description. A reposi- 
tory accessible in the network facilitates the building of 
interface descriptions which can be easily shared. Any 
differences between the input document created for a par- 
ticular process and the output document expected as a return 

15 by a complementary process can be easily negotiated by 
communication on the network and agreeing on common 
logic structures to express particular information. 

The machine-readable specification of an interface of a 
transaction according to one aspect of the invention includes 

20 a document compliant with a definition of an interface 
document that is shared amongst members of the network. 
A definition of the interface document includes logic struc- 
tures for storing an identifier of a particular transaction and 
at least one of definitions and references to definitions of 

25 input and output documents for the particular transaction. 
That is, the interface description for a particular service may 
actually encompass a definition of the input and output 
documents. Alternatively, it may include pointers to a loca- 
tion in the repository, or elsewhere in the network, of such 

30 definitions. 

According to another alternative of the invention, the 
machine -readable specification includes a business interface 
definition BID document compliant with a definition of an 

35 interface document that includes logical structures for stor- 
ing an identifier of the interface, and for storing at least one 
of specifications and references to specifications of a set of 
one or more transactions supported by the interface. For 
each supported transaction, the document includes at least 

4Q one of definitions and references to definitions of input and 
-output documents for the particular transaction. 

According to another aspect of the invention, the storage 
units defined in the definitions of the input and output 
document comprise parsed data including character data 

45 encoding text characters, and mark-up data identifying sets 
of storage units according to the logical structures of the 
input and output documents. According to another aspect of 
the invention, at least one of the sets of storage units encodes 
the plurality of text characters providing a natural language 

50 word. This facilitates the use of the definitions of input and 
output documents by human readers and developers of such 
documents. 

According to another aspect of the invention, the speci- 
fication of the input and output documents includes inter- 

55 pretation information for at least one of the sets of storage 
units identified by the logical structure. The interpretation 
information in one example encodes definitions for sets of 
parsed characters. In another example, the interpretation 
information provides for content model specifications, such 

60 as requiring a specific logic structure to carry a member of 
a list of codes mapped to product descriptions in a catalog. 
In some systems, the storage units in a logic structure of a 
document may include sets of unparsed data, as suits the 
needs of a particular implementation. 

65 According to yet another aspect of the invention, the 
transaction process in a particular platform has a transaction 
processing architecture which is one of a plurality of variant 
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transaction processing architectures. Thus the participant of the transaction processes into sets of storage units and 
node includes resources for translating at least a portion of logical structures of the output document, 
the input document into a format readable according to the The tools to build a definition of a participant interface in 
variant transaction processing architecture of the transaction a preferred system include instructions executable by the 
process utilizing the information. The elements of the docu- 5 system to access elements of the definition from comple- 
ment definition are translated into programming objects that mentary nodes and/or from a repository that stores a library 
include variables and methods according to the variant of logical structures and interpretation information for logi- 
transaction processing architectures of the transaction pro- cal structures used to build interface descriptions. According 
cess. For a participant having a JAVA virtual machine acting to various aspects of the invention, the repository includes 
as a transaction process front end, particular fields in the 1Q not only a library of logical structures but definitions of 
documents are translated into JAVA objects, including the documents that comprise logical structures, and formats for 
data as well as get and set functions associated with a JAVA specifying participant interfaces. According to this aspect of 
object. Other transaction processing architectures support- the invention, tools are provided for building specifications 
able according to the present invention include processes of business interfaces according to the techniques described 
compliant with an interface description language in the 15 above in connection with the description of the participant 
sense of Common Object Request Broker Architecture nodes. The tools for building interfaces and the tools for 
CORBA, Component Object Model COM, On-Line Trans- compiling the interfaces into resources needed for cornmu- 
action Processing OLTP, and Electronic Data Interchange nication with transaction processing architectures according 
EDI. to this aspect of the invention, are implemented in partici- 

According to other aspects of the invention, a repository 2Q pant nodes in the preferred system, and utilized for the 

is provided that stores document types for use in the plurality development and optimization of the interface descriptions 

of transactions. The machine -readable specification for a as use of the network grows based on interface descriptions 

particular transaction defines at least one of the input and that define input and output documents, 

output documents by reference to a document type in the Accordingly, another aspect of the invention provides an 

repository. According to another aspect, the document type 25 apparatus that includes memory and a data processor that 

included in the repository include a document type for executes instructions stored in the memory that include tools 

identifying participants in the network. Such document type to build a definition of a participant interface and a compiler 

providing structures for identifying a participant, specifying performing the functions described above, 

the services supported by the participant, and specifying the According to yet another aspect of the invention, the use 

input and output documents for each of such services. 30 0 f the participant interface descriptions enables the opera- 

In addition to the methods described above, the present tion of a market maker node. At such a node, a method for 

invention provides an apparatus for managing transactions managing transactions is provided that comprises storing 

among nodes that includes a network interface, memory for machine-readable specifications of a plurality of participant 

storing data and programs of instructions including a interfaces which identify transactions supported by the 

machine -readable specification of an interface for a trans- 35 interfaces, and the respective input and output documents of 

action as described above, and a data processor that is such transactions. As described above, the definitions of the 

coupled with the memory and the network interface. The input and output documents comprise respective descrip- 

programs of instructions stored in the apparatus include tions of sets of storage units and logical structures for the 

logic to execute the processes described above for a partici- sets of storage units, such as according to the XML standard, 

pant in the transactions. 40 In addition, the definitions of the transactions and the 

The present invention further provides an apparatus for definitions of the participant interfaces all comprise docu- 

establishing participant interfaces for transactions executed ments specified according to a technique compliant with 

on a system that include a network interface and a data XML or other standardized document expression language, 

processing resources that execute transaction processes At such market maker node, data comprising a document is 

according to a transaction processing architecture. The appa- 45 received over a communication network. The document is 

ratus includes programs of instructions that are executable parsed according to the specifications to identify an input 

by the system and stored on a medium accessible by the document in one or more transactions which accept the 

system that provide tools to build a definition of a participant identified input document. At least a portion of the input 

interface for a participant in a particular transaction. The document is provided in a machine-readable format to a 

definition of a participant interface includes a definition of 50 transaction process associated with the one or more identi- 

an input document and a definition of an output document. fied transactions. The step of providing at least a portion of 

The definitions of the input and output documents comprise the input document to a transaction process includes execut- 

respective machine -readable descriptions of sets of storage ing a routing process according to a processing architecture 

units in logical structures for the sets of storage units, which at the market maker node. The routing process in one aspect 

may be compliant in one aspect of the invention with XML 55 of the invention is executed according to a particular pro- 

document type definitions. cessing architecture, and at least a portion of the incoming 

The apparatus for establishing participant interfaces document is translated into the format of the processing 
according to this aspect of the invention also includes architecture of the routing process. The translating accord- 
programs of instructions stored on a medium accessible by ing to the preferred aspect includes producing programming 
the data processing system and responsive to the definitions 60 objects that include variables and methods according to the 
of input and output documents to compile data structures processing architecture of the routing process, 
corresponding to the sets of storage units and logical struc- According to another aspect of the invention, the market 
tures of the input and output documents that are compliant maker node also supports the repository structure. Thus, a 
with the transaction processing architecture, to compile process is included at the market maker node for allowing 
instructions executable by the system to translate the input 65 access by participants in the network to a repository stored 
document to the corresponding data structures, and to com- at the market maker node. As described above, the reposi- 
pile instructions executable by the system to translate output tory includes definitions of logic structures, interpretation 
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information, and document definitions for use by the par- 
ticipant nodes to build transaction interface documents and 
includes instances of business interface definitions that 
identify the participants, and the transactions executed by 
the respective participants. 

The routing process includes according to various alter- 
natives the translating of the input document into the variant 
processing architecture of the processes to which the docu- 
ment is to be routed, or routing the input document in its 
original document format across the network to a remote 
processing node, or to combinations of such processes. In 
alternatives, the routing process may also include techniques 
for transforming an input document defined according to one 
input document definition into a different document defined 
according to a different document specification for a process 
which has registered to watch for the input document. 

Also, the market maker node is provided according to the 
present invention as apparatus that includes a network 
interface, memory storing data and programs of instructions 
including the specifications of the participant interfaces, and 
a data processor. The logic is provided with the data pro- 
cessor in the form of programs of instructions or otherwise 
to perform the market maker process as discussed above. 

Accordingly, the present invention provides a foundation 
for electronic commerce based on the sharing of specifica- 
tions of input and output documents. Documents provide an 
intuitive and flexible way to access business services, much 
simpler to implement than programming APIs. It is much 
easier to interconnect companies in terms of documents that 
are exchanged, on which such companies already largely 
agree, than in terms of business system interfaces which 
invariably differ. In addition, such documents are specified 
in a human readable format in the preferred embodiment. 
According to the present invention the business interfaces 
are specified in documents, such as XML documents that are 
readily interpretable by humans as well as by computers. 

Utilization of the document based transaction architecture 
of the present invention involves the use of a parser which 
operates in basically the same way for any source of 
documents, eliminating much of the need for custom pro- 
grams to extract and integrate information from each par- 
ticipant in the network. Thus, integrating enterprise infor- 
mation from accounting, purchasing, manufacturing, 
shipping and other functions can be accomplished by first 
converting each source to a document having an architecture 
according to the present invention, and then processing the 
parsed data stream. Each node in the system that participates 
in the market only needs to know about the format of its 
internal systems, as well as the format of the documents 
being specified for interchange according to the transaction. 
Thus, there is no need to be able to produce the native format 
of every other node which might want to participate in the 
electronic commerce network. 

For complete business integration, the present invention 
provides a repository of standardized logical structures, like 
XML elements, attributes or meta data, establishing a 
semantic language for particular commerce communities, a 
means for mapping between different meta data 
descriptions, and a server for processing the documents and 
invoking appropriate applications and services. The basic 
building blocks of a network according to the present 
invention include the business interface definitions which 
tell potential trading partners what online services a com- 
pany offers and which documents to use to invoke the 
services; and servers which provide the bridge to bind 
together the set of internal and external business services to 
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create a trading community. The server operates to parse the 
incoming documents and invoke the appropriate services. 
Also the server according to the present invention handles 
the translation tasks from the format of the documents being 

5 received and transmitted, to and from the formats of the 
respective host systems. Thus, trading partners need only 
agree on the structure, content and sequencing of the busi- 
ness documents exchanged, and not on the details of appli- 
cation programmer interfaces. How a document is processed 

10 and the actions which result from receipt of a document arc 
strictly up to the businesses providing the services. This 
elevates integration from the system level to the business 
level. It enables the business to present a clean and stable 
interface to its partners despite changes in its internal 

15 technology implementation, organization or processes. 

The whole process of building business interface defini- 
tions and enabling servers to manage commerce according 
to such descriptions is facilitated by a common business 
library, or repository, of information models for generic 

20 business concepts including business description primitives 
like companies, services and products, business forms like 
catalogs, purchase orders and invoices, and standard 
measurements, including time and date, location and clas- 
sification of goods. 

25 Other aspects of the present invention can be seen upon 
review of the figures, the detailed description, and the claims 
which follow. 

BRIEF DESCRIPTION OF THE FIGURES 

30 FIG. 1 is a simplified diagram of an electronic commerce 
network including business interface definitions BIDs 
according to the present invention. 

FIG. 2 is a simplified diagram of a business interface 
definition document according to the present invention. 

FIG. 3 is a conceptual block diagram of a server for a 
participant node in the network of the present invention. 

FIG. 4 is a flow chart illustrating the processing of a 
received document at a participant node according to the 
40 present invention. 

FIG. 5 is a block diagram of a parser and transaction 
process front end for an XML based system. 

FIG. 6 is a conceptual diagram of the flow of a parse 
function. 

45 FIG. 7 is a simplified diagram of the resources at a server 
used for building a business interface definition according to 
the present invention. 

FIG. 8 is a simplified diagram of a repository according 
to the present invention for use for building business inter- 
50 face definitions. 

FIG. 9 is a flow chart illustrating the processes of building 
a business interface definition according to the present 
invention. 

55 FIG. 10 provides a heuristic view of a repository accord- 
ing to the present invention. 

FIG. 11 is a simplified diagram of the resources at a server 
providing the market maker function for the network of the 
present invention based on business interface definitions. 

60 FIG. 12 is a flow chart for the market maker node 
processing of a received document. 

FIG. 13 is a flow chart illustrating the process of regis- 
tering participants at a market maker node according to the 
present invention. 

65 FIG. 14 is a flow chart illustrating the process of provid- 
ing service specifications at a market maker node according 
to the process of FIG. 9. 
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FIG. 15 is a diagram illustrating the sequence of operation 
at a participant or market maker node according to the 
present invention. 

FIG. 16 is a conceptual diagram of the elements of a 
commercial network based on BIDs, according to the 
present invention. 

DETAILED DESCRIPTION 

A detailed description of the present invention is provided 
with respect to the figures, in which FIG. 1 illustrates a 
network of market participants and market makers based on 
the use of business interface definitions, and supporting the 
trading of input and output documents specified according to 
such interface descriptions. The network includes a plurality 
of nodes 11-18 which are interconnected through a com- 
munication network such as the Internet 19, or other tele- 
communications or data communications network. Each of 
the nodes 11-19 consists of a computer, such as a portable 
computer, a desktop personal computer, a workstation, a 
network of systems, or other data processing resources. The 
nodes include memory for storing the business interface 
definition, processors that execute transaction processes 
supporting commercial transactions with other nodes in the 
network, and computer programs which are executed by the 
processors in support of such services. In addition each of 
the nodes includes a network interface for providing for 
communication across the Internet 19, or the other commu- 
nication network. 

In the environment of FIG. 1, nodes 11, 12, 13, 14, 16 and 
18 are designated market participants. Market participants 
include resources for consumers or suppliers of goods or 
services to be traded according to commercial transactions 
established according to the present invention. 

In this example, nodes 15 and 17 are market maker nodes. 
The market maker nodes include resources for registering 
business interface definitions, called a BID registry. Partici- 
pants are able to send documents to a market maker node, at 
which the document is identified and routed to an appropri- 
ate participant which has registered to receive such docu- 
ments as input. The market maker also facilitates the com- 
mercial network by maintaining a repository of standard 
forms making up a common business library for use in 
building business interface definitions. 

In this example, the market participant 18 is connected 
directly to the market maker 17, rather than through the 
Internet 19. This connection directly to the market maker 
illustrates that the configuration of the networks supporting 
commercial transactions can be very diverse, incorporating 
public networks such as the Internet 19, and private con- 
nections such as a local area network or a Point-to-Point 
connection as illustrated between nodes 17 and 18. Actual 
communication networks are quite diverse and suitable for 
use to establish commercial transaction networks according 
to the present invention. 

FIG. 2 is a heuristic diagram of nested structures in a 
business interface definition BID which is established for 
market participants in the network according to the present 
invention. The business interface definition illustrated in 
FIG. 2 is a data structure that consists of logic structures and 
storage units arranged according to a formal definition of a 
document structure, such as a XML document type defini- 
tion DTD. The structure of FIG. 2 includes a first logic 
structure 200 for identifying a party. Associated with the 
logic structure 200 are nested logic structures for carrying 
the name 201, the physical address 202, the network address 
or location 203, and a set of transactions for a service 204. 
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For each transaction in the service set, an interface definition 
is provided, including the transaction BID 205, the transac- 
tion BID 206, and the transaction BID 207. Within each 
transaction BID, such as transaction BID 205, logical struc- 

5 tures are provided for including a name 208, a location on 
the network at which the service is performed 209, the 
operations performed by the service 210, and a set of input 
documents indicated by the tag 211. Also, the service BID 
205 includes a set of output documents indicated by the tag 

10 212. The set of input documents 211 includes a business 
interface definition for each input document for which the 
services are designed to respond, including input document 
business interface definitions 213, 214, and 215. Each busi- 
ness interface definition for an input document includes a 

15 name 216, a location on the network at which a description 
of the document can be found 217, and the modules to be 
carried in the document as indicated by the field 218. In a 
similar manner, the output document set 212 includes inter- 
face definitions for output documents including the output 

20 document BID 219, output document BID 220, and output 
document BID 221. For each output document BID, a name 
222, a location on the network or elsewhere 223, and the 
modules of the document 224 are specified. The business 
interface definition for the participant as illustrated in FIG. 

25 2 includes actual definitions of a logic structures to be 
utilized for the input and output documents of the respective 
services, or pointers or other references to locations at which 
these definitions can be found. 
In the preferred system, the document of FIG. 2 is 

30 specified in an XML document type definition DTD, 
although other document definition architectures could be 
used, and includes interpretation information for the logical 
structures used in interpretation of instances of the docu- 
ments. In addition, each of the transaction BIDs, input 

35 document BIDs and output document BIDs are specified 
according to an XML document type definitions. The XML 
type document is an example of a system based on parsed 
data that includes mark-up data and character data. Mark-up 
data identifies logical structures within the document and 

40 sets of character data identify the content of the logical 
structures. In addition, unparsed data can be carried in the 
document for a variety of purposes. See for example the 
specification of the Extensible Mark-up Language XML 1.0 
REC-XML-19980210 published by the WC3 XML Working 

45 Group at WWW.W3.ORG/TR/1998/REC-XML-19980210. 
Thus in an exemplary system, participant nodes in the 
network establish virtual enterprises by interconnecting 
business systems and services with XML encoded docu- 
ments that businesses accept and generate. For example, the 

50 business interface definition of a particular service estab- 
lishes that if a document matching the BID of a request for 
a catalog entry is received, then a document matching a BID 
of a catalog entry will be returned. Also, if a document 
matching the BID of a purchase order is received, and it is 

55 acceptable to the receiving terminal, a document matching 
the BID of an invoice will be returned. The nodes in the 
network process the XML documents before they enter the 
local business system, which is established according to the 
variant transaction processing architecture of any given 

60 system in the network. Thus, the system unpacks sets of 
related documents, such as MIME-encoded sets of XML 
documents, parses them to create a stream of "mark-up 
messages". The messages are routed to the appropriate 
applications and services using for example an event listener 

65 model like that described below. 

The documents exchanged between business services are 
encoded using an XML language built from a repository of 
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building blocks (a common business language) from which 
more complex document definitions may be created. The 
repository stores modules of interpretation information that 
are focused on the functions and information common to 
business domains, including business description primitives 5 
like companies, services and products; business forms like 
catalogs, purchase orders and invoices; standard 
measurements, like time, date, location; classification codes 
and the like providing interpretation information for logical 
structures in the XML documents. 10 

The business interface definition is a higher level docu- 
ment that acts as a schema used for designing interfaces that 
trade documents according to the present invention. Thus the 
business interface definition bridges the gap between the 
documents specified according to XML and the programs 15 
which execute on the front end of the transaction processing 
services at particular nodes. Such front ends are imple- 
mented by JAVA virtual machines, or by other common 
architectures providing for interconnection of systems 
across a network. Thus, the business interface definition 20 
provides a technique by which a transaction protocol is 
programmed using the business interface definition docu- 
ment. The program for the protocol of the transaction is 
established by a detailed formal specification of a document 
type. 25 

An example business interface definition BID based on a 
market participant document which conforms to an XML 
format is provided below. The market participant DTD 
groups business information about market participants, asso- 
ciating contact and address information with a description of 30 
services and financial information. This business informa- 
tion is composed of names, codes, addresses, a dedicated 
taxonomic mechanism for describing business organization, 
and a pointer to terms of business. In addition, the services 
identified by the market participant DTD will specify the 35 
input and output documents which that participant is 
expected respond to and produce. Thus, documents which 
define schema using an exemplary common business lan- 
guage for a market participant DTD, a service DTD, and a 
transaction document DTD specified in XML with explana- 40 
tory comments follow: 

Market Participant Sample 



<!DOCTYPE SCHEMA SYSTEM "bid!.dtd"> 
<SCHEMA> 

<Hl>Market Participant Sample BIEWH1> 
<META 

WHO.OWNS="Veo Systems" WHO.COPYRIGHT="VeoSystems" 
WHCN.COPYRIGHT="1998" DESCRIPTION="Sample BID" 
WHO.CREATED="*" WHEN.CREATED=" *" 

WHAT. VERSION**"*" WHO.MODIFIED="*" 
WHEN.MODIFIED="*" WHEN. EFFECT! VE=" *" 

WHEN. EXP IRES="*" < WHO. EFFECTIVE-"*" 

WHO.EXPIRES="*"> 
</META> 



<PROLOG> 

<XMLDECL STAND ALONE="no"x/XMLDECL> 
<DOCTYPE NAME="market.participant"> 60 
<SYSTEM>markpart.dtd</SYSTEMx/DOCTYPE> 
<PROLOG> 

<DTD NAME="markpart.dtd"> 

<H2>Market Participant</H2> 65 
<H3>Market Participant</H3> 
<ELEMENTTYPE NAME-"market.participant"> 
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<EXPLAIN>< TITLE>A Market Participant<mTLE> 
<SYNOPSIS>A business or person and its service 

interfaces.</SYNOPSIS> 
<P>A market participant is a document definition that is 
created to describe a business and at least one person 
with an email address, and it presents a set of pointers 
to service interfaces located on the network. In this 
example, the pointers have been resolved and the 
complete BID is presented here.</Px/EXPLAIN> 
<MODELxCHOICE> 

<ELEMENT NAME=" business" > </ELEMENT> 
<ELEMENT NAME="person"x/ELEMENT> 
</CHOICE></MODEL></ELEMEOTTYPE> 
<H3>Party Prototype</H3> 
PROTOTYPE NAME="party"> 
<EXPLAINxTITLE>The Party Prototype</TITLEx/ 

EXPLAIN> 
<MODELxSEQUENCE> 

<ELEMENT NAME="party.name" OCCURS-" +"x/ 
ELEMENT> 

<ELEMENT NAME="address.set , *x/ELEMENT> 
</SEQUENCEx/MODEL> 
</PROTOTYPE> 
<H3>Party Types</H3> 
<ELEMENTTYPE NAME="business"> 
<EXPLAINxTITLE>A Business</TITLE> 
<SYNOPSIS>A business (party) with a business number 

attribute. <SYNOPSIS> 
<P>This element inherits the content model of the party 
prototype and adds a business number attribute, which 
serves as a key for database lookup. The business 
number may be used as a cross-reference to/from 
customer id, credit limits, contacts lists, etc.</P></ 
EXPLAIN> 
<EXTENDS HREF="party"> 

< ATTDEF N AME = 

"business.number"xREQUIREDx/REQUIRED></ 
ATTDEF> 
</EXTENDS> 
</ELEMENTTYPE> 
<H3>Person Name</H3> 
<ELEMENTTYPE NAME«"person"> 
<EXPLAINxTITLE>A Person</TITLEx/EXPLAlN> 
<EXTENDS HREF="party"> 

<ATTDEF NAME-"SSN"xIMPLIEDx/IMPLIEDx/ 

ATTDEF> 
</EXTENDS> 
</ELEMENTTYPE> 
<H3>Party Name</H3> 
<ELEM ENTTYPE NAME="party.name"> 
<EXPLAINxTITLE>A Party's Name</TTTLE> 
<SYNOPSIS>A party's name in a string of characters/ 

SYNOPSISx/EXPLAIN> 
<MODELxSTRINGx/STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>Address Set</H3> 
<ELEMENTTYPE NAME="address.set"> 
<MODELxSEQUENCE> 

<ELEMENT NAME«" address .physicar'x/ELEMENT> 
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<ELEMENT NAM E=" telephone" OCCURS="*"></ 
ELEMENT> 

<ELEMENT NAME="fax" OCCURS="*"x/ 
ELEMENT> 

<ELEMENT NAME="emair OCCURS«"*"x/ 5 
ELEMENT> 

<ELEMENT NAME«"internet" OCCURS="*"></ 
ELEMENT> 

</SEQUENCEx/MODEL> 10 
</ELEMENTTYPE> 
<H3>Physical Address</H3> 
<ELEMENTTYPE NAME=" address.physicar> 
<EXPLAIN><TITLE> Physical Address<yTITLE> 15 
<SYNOPSIS>The street address, city, state, and zip 

code.</SYNOPSISx/EXPLAIN> 
<MODELxSEQUENCE> 
<ELEMENT NAME="street"x/ELEMENT> 
<ELEMENT NAME="city"x/ELEMENT> 20 
<ELEMENT NAME="state">/ELEMENT> 
<ELEMENT NAME«"postcode" OCCURS«"?"></ 

ELEMENT> 

<ELEMENT NAME-"country"x/ELEMENT> 25 

</SEQUENCEx/MODEL> 

</ELEMENTTYPE> 

<H3>Street</H3> 

<ELEMENTTYPE NAME="street"> 
<EXPLAINxTITLE>Street Address</TITLE> 
<SYNOPSIS>Street or postal address. </SYNOPSIS></ 
EXPLAIN> 

<MODELxSTRINGx/STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>City</H3> 

<ELEMENTTYPE NAME="city"> 

<EXPLAIN><TITLE>City Name or Code</TITLE> 

<P>The city name or code is a string that contains 
sufficient information to identify a city within a desig- 
nated state.</P> 

</EXPLAIN> 

<MODELxSTRINGx/STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>State</H3> 

<ELEMENTTYPE NAME="state"> 

<EXPLAINxTITLE>State, Province or Prefecture 
Name or Code</TITLE> 

<P>The state name or code contains sufficient informa- 
tion to identify a state within a designated country.</ 
Px/EXPLAIN> 

<MODEL><STRING DATATYPE- 55 

"COUNTRY.US.SUBENTITY"x/STRING></ 
MODEL> 

</ELEMENTTYPE> 

<H3>Postal Code</H3> 

<ELEMENTTYPE NAME="postcode"> 

<EXPLAINxTITLE>Postal Code</TITLE> 

<P>A postal code is an alphanumeric code, designated by 
an appropriate postal authority, that is used to identify 
a location or region within the jurisdiction of that postal 65 
authority. Postal authorities include designated national 
postal authorities.</Px/EXPLAIN> 



30 
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50 



60 



<MODELxSTRING DATATYPE="string"></ 

STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>Country</H3> 
<ELEMENTTYPE NAME-" country's 
<EXPLAINxTITLE>Country Code</TITLE> 
<P>A country code is a two-letter code, designated by 

ISO, that is used to uniquely identify a country.</P></ 

EXPLAIN> 

<MODELxSTRING DATATYPE-"country"></ 

STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>Network Addresses</H3> 
<ELEM ENTTYPE NAME=" telephone" > 
<EXPLAINxTITLE>Telephone Number</TITLE> 
<P>A telephone number is a string of alphanumerics and 

punctuation that uniquely identifies a telephone service 

terminal, including extension number. </Px/ 

EXPLAIN> 

<MODELxSTRINGx/STRINGx/MODEL> 

</ELEMENTTYPE> 

<H3>Fax</H3> 

<ELEMENTTYPE NAME="fax"> 
<EXPLAINxTITLE>Fax Number </TlTLE> 
<P>A fax number is a string of alphanumerics and punc- 
tuation that uniquely identifies a fax service terminal^/ 
P> 

</EXPLAIN> 

<MODELxSTRINGx/STRINGx/MODEL> 

</ELEMENTTYPE> 

<H3>Email</H3> 

<ELEM ENTTYPE NAME-"emaiT> 
<EXPLAINxTITLE>Email Address</nTLE> 
<P>An email address is a datatype-constrained string that 

uniquely identifies a mailbox on a server. </P></ 

EXPLAIN> 

<MODELxSTRING DATATYPE-"email"></ 

STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>Internet Address</H3> 
<ELEMENTTYPE NAME="interaet"> 
<EXPLAINxTITLE>Internet Address</TITLE> 
<P>An Internet address is a datatype-constrained string 

that uniquely identifies a resource on the Internet by 

means of a URL.</Px/EXPLAIN> 
<MODELxSTRING DATATYPE="urF'x/STRINGx/ 

MODEL> 
</ELEMENTTYPE> 
</DTD> 
</SCHEMA> 

Service Description Sample 



<!DOCTYPE SCHEMA SYSTEM "bidl.dtd"> 
<SCHEMA> 

<Hl>Servicc Description Sample BID</H1> 
<META 

WHO.OWNS-"Veo Systems" WHO.COPYRIGHT-" VeoSystems" 
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WHEN. COPYRIGHT-" 1998" 
WHO.CREATED-"*'* 
WHAT.VERSION-"*" 
WHEN.MODIFIED-""" 
WHEN. EXPIRES- 4 '*" 

WHO.EXPIRES- > 

</META> 



DESCRIPTION="Sample BID" 

WHEN.CREATED- 

WHO. MODIFIED-"*" 
WHEN. EFFECTIVE-"*" 
WHO. EFFECT! VE-" *" 
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<PROLOG> 

<XMLDECL STANDALONE-" no"x/XMLDECL> 
<DOCTYPE NAME="service"> 
<SYSTEM>service.dtd</SYSTEMx/DOCTYPE> 
</PROLOG> 

<DTD NAME="service.dtd"> 
<H2>Services</H2> 
<H3>Includes</H3> 

<!--INCLUDE><SYSTEM>commcnts.bim</ 

SYSTEMx/INCLUDE«> 
<H3>Service Set</H3> 
<ELEMENTTYPE NAME="service.set"> 
<EXPLAIN><TITLE>Service Set</nTLE> 25 
<SYNOPSIS>A set of services.</SYNOPSIS></ 

EXPLAIN> 
<MODEL> 

<ELEMENT NAME«"service" OCCURS="+"x/ 

ELEMENTS 
</MODELx/ELEMENTTYPE> 
<H3>Services Prototype </H3> 
<PROTOTYPE NAME="prototype.service"> 
<EXPLAIN><TlTLE>Service</TITLE></EXPLAIN> 
<MODELxSEQUENCE> 

<ELEMENT NAME-"service.name"x/ELEMENT> 
<ELEMENT NAME="service. terms" OCCURS-" +"x/ 
ELEMENT> 

<ELEMENT NAME="service.location" OCCURS-"+ 

"></ELEMENT> 
<ELEMENT NAME-"service. operation" OCCURS-" + 

"></ELEMENT> 
</SEQUENCEx/MODEL> 

<! - -ATTGROUPxIMPLEMENTS HREF- 
"common, a ttrib"x/IMPLEM ENTSx/ 
ATTGROUP--> 

</PROTOTYPE> 

<H3>Service</H3> 

<INTROxP>A service is an addressable network 
resource that provides interfaces to specific operations 
by way of input and output documents.</Px/INTRO> 

<ELEMENTTYPE NAME-"service"> 

<EXPL^N><TlTLE>Service</TITLE> 

<P>A service is defined in terms of its name, the location 
(s) at which the service is available, and the operation 
(s) that the service performs.</Px/EXPLAIN> 

<MODELxSEQUENCE> 

<ELEMENT NAME-" service. name" ></ELEMENT> 
<ELEMENT NAME-" service. location"x/ELEMENT> 
<ELEMENT NAME-"service.operation" OCCURS-" + 

"></ELEMENT> 
<ELEMENT NAME-" service. terms" x/ELEMENT> 
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</SEQUENCEx/MODEL> 

</ELEMENTTYPE> 

<H3>Service Name</H3> 

<ELEMENTTYPE NAME=" service. name" > 

<EXPLAINxTITLE>Service Namc</TITLE> 

<P>The service name is a human-readable string that 

ascribes a moniker for a service. It may be employed is 

user interfaces and documentation, or for other 

purposes.</Px/EXPLAIN> 
<MODELxSTRINGx/STRINGx/MODEL> 
</ELEMENTTYPE> 
<H3>Service Location</H3> 
<ELEMENTTYPE NAME=" service. location"> 
<EXPLAINxTITLE>Service I^cation<mTLE> 
<SYNOPSIS>A URI of a service.</SYNOPSIS> 
<P>A service location is a datatype-constrained string that 

locates a service on the Internet by means of a URI.</ 

Px/EXPLAIN> 
<MODELxSTRING DArATYPE="url"x/STRING></ 

MODEL> 
</ELEMENTTYPE> 
<H3>Service Operations</H3> 

<INTRO><P>A service operation consists of a name, 
location and its interface, as identified by the type of 
input document that the service operation accepts and 
by the type of document that it will return as a result.</ 
Px/INTRO> 
<ELEMENTTYPE NAME«"service .operation" > 
<EXPLAINxTlTLE>Service Operations</TITLE> 
<P>A service operation must have a name, a location, and 
at least one document type as an input, with one or 
more possible document types returned as a result of 
the operation.</P> 
</EXPLAIN> 
<MODELxSEQUENCE> 

<ELEMENT NAME-"service.operation.name"x/ 
ELEMENTS 

<ELEMENT NAME="service.operation.location"x/ 
ELEMENTS 

<ELEMENT NAME-"service.operation.input"x/ 
ELEMENT> 

<ELEMENT NAME-"service.operation.output"x/ 

ELEMENT> 
</SEQUENCEx/MODEL> 
</ELEMENTTYPE> 
<H3>Service Operation Name</H3> 
<ELEMENTTYPE NAME="service.operation.name"> 
<EXPLAIN><TITLE>Service Operation Name</ 

TITLE> 

<P>The service operation name is a human-readable 
string that ascribes a moniker to a service operation. It 
may be employed in user interfaces and documentation, 
or for other purposes.</Px/EXPLAIN> 

<MODELxSTRINGx/STRINGx/MODEL> 

</ELEMENTTYPE> 

<H3>Service Operation Location</H3> 

<INTROxP>The service location is a network resource. 
That is to say, a URI.</Px/INTRO> 

<ELEM ENTTYPE NAME- 
"service . operation . location"> 
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<EXPLAINxTITLE>Service Operation Location</ 
TITLE> 

<SYNOPSIS>A URI of a service operation^/ 
SYNOPSIS> 

<P>A service operation location is a datatype-constrained 5 
string that locates a service operation on the Internet by 
means of a URL.</Px/EXPLAIN> 

<MODEL><STRING DATATYPE="url M ></STRING></ 
MODEL> 

</ELEMENTTYPE> 30 
<H3>Service Operation Input Document</H3> 
<INTRO><P>The input to a service operation is defined 
by its input document type. That is, the service opera- 
tion is invoked when the service operation location 15 
receives an input document whose type corresponds to 
the document type specified by this element.</P> 
<P>Rather than define the expected input and output 
document types in the market participant document, 
this example provides pointers to externally-defined 20 
BIDs. This allows reuse of the same BID as the input 
and/or output document type for multiple operations. In 
addition, it encourages parallel design and 
implementation.</Px/INTRO> 
<ELEMENTTYPE NAME="service.operation.input"> 25 
<EXPLAINxTITLE>Service Operation Input</TITLE> 
<SYNOPSIS>Identifies the type of the service operation 

input document.</SYNOPSIS> 
<P>Service location input is a datatype -constrained string 3Q 
that identifies a BID on the Internet by means of a 
URI.</P> 
</EXPLAIN> 

<MODEL><STRING DATArYPE="url"x/STRING></ 

MODEL> 35 
</ELEMENTTYPE> 

<H3>Service Operation Output Document Type</H3> 
<INTROxP>The output of a service operation is defined 
by its output document type(s). That is, the service 
operation is expected to emit a document whose type 40 
corresponds to the document type specified by this 
element</Px/INTRO> 

<ELEMENTTYPE NAME="service.operation,output"> 
<EXPLAINxTITLE>Service Operation Output</ 45 
TTTLE> 

<SYNOPSIS identifies the type of the service operation 

output document.</SYNOPSIS> 
<P>Service location output is a datatype-constrained 

string that identifies a BID on the Internet by means of 50 

a URI.</P> 
</EXPLAIN> 

<MODELxSTRING DATATYPE«"urrx/STRINGx/ 
MODEL> 

</ELEMENTTYPE> 55 
<H3>Service Terms</H3> 

<INTROxP>This is a simple collection of string 
elements, describing the terms of an agreement. <!?><! 
INTRO> 

<ELEMENTTYPE NAME="service.terms"> 60 
<EXPLAIN><TITLE>Service Terms</T1TLE> 
<SYNOPSIS>Describes the terms of a given 

agrecment.</SYNOPSIS> 
</EXPLAIN> 65 
<MODEL><STRING DATATYPE-" string"></ 

STRINGx/MODEL> 
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</ELEMENTTYPE> 

</DTD> 

</SCHEMA> 

The service DTD schema may be extended with a service 
type element in a common business language repository as 
follows: 

<! ELEMENT service .type EMPTY> 
<!ATTLIST service.type 
service.type.name ( 
catalog.operator 
commercial.directory.operator 
eft.se rviccs.provider 
escrower 

fulfillment .service 

insurer 

manufacturer 

market .operator 

order.originator 

ordering.se rvice 

personal.se rviccs.provider 

retailer 

re tail. aggregator 

schema. resolution. service 

service .provider 

shipment.acceptor 

shipper 

van 

wholesale, aggregator 

) #REQUIRED 

%common.attrib; 
The service type element above illustrates interpretation 
information carried by a business interface definition, in this 
example a content form allowing identification of any one of 
a list of valid service types. Other interpretation information 
includes data typing, such as for example the element 
<H3>Internet Address</H3> including the content form 
"url" and expressed in the data type "string." Yet other 
interpretation information includes mapping of codes to 
elements of a list, such as for example the element 
<H3>State</H3> including the code mapping for states in 
the file "COUNTRY.US.SUBENTITY." 

The service description referred to by the market partici- 
pant DTD defines the documents that the service accepts and 
generates upon competition of the service. A basic service 
description is specified below as a XML document trans- 
acted. 

Transact.dtd models a transaction description, such as an 
invoice, or a description of an exchange of value. This 
document type supports many uses, so the transaction 
description element has an attribute that allows user to 
distinguish among invoices, performance, offers to sell, 
requests for quotes and so on. The exchange may occur 
among more than two parties, but only two are called out, 
the offeror and the counter party, each of whom is repre- 
sented by a pointer to a document conforming to the market 
participant DTD outlined above. The counter party pointer is 
optional, to accommodate offers to sell. The exchange 
description is described in the module tranprim.mod listed 
below, and includes pricing and subtotals. Following the 
exchange description, charges applying to the transaction as 
a whole may be provided, and a total charge must be 
supplied. Thus, the transaction description schema docu- 
ment transact.dtd for this example is set forth below: 
<! -transact.dtd Version: 1.0 --> 
<! -Copyright 1998 Veo Systems, Inc. --> 

<!ELEMENT transaction. description (meta?, 
issuer.pointer, 
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counterparty. pointer?, exhange.descrption+, 
general.charges?, net.total?)> 
<! ATI LIST transaction .description 
transaction. type (invoice | pro. forma | offer, to .sell | 
order 

request. for. quote | request. for.bid 
request. for. proposal | response. to. request. for.quote 
response.to.request.for.bid 
response.to.request.for.proposal) "invoice" 
%common.attrib; 
%altrep.attrib; 
%ttl. attrib; 

> 

Representative market participant, and service DTDs, 
created according to the definitions above, are as follows: 
Market Participant DTD 

<! ELEMENT business (party.name+, address.set)> 
<!ATTLIST business business. number CD ATA 

#REQUIRED 
<! ELEMENT party.name (#PCDATA)> 
<! ELEMENT city (#PCDATA)> 
<! ELEMENT internet (#PCDATA)> 
<! ELEMENT country (#PCDATA)> 
<! ELEMENT state (#PCDATA)> 
<! ELEMENT email (#PCDATA)> 
<!ELEMENT address. physical (street, city, state, 

postcode?, country) > 
<! ELEMENT telephone (#PCDATA)> 
<! ELEMENT person (party.name+, address.set) > 
<!ATTLIST person SSN CD ATA #IMPUED> 
<! ELEMENT fax (#PCDATA)> 
<! ELEMENT street (#PCDATA)> 
<! ELEMENT address.set (address.physical, telephone*, 

fax*, email*, internet*) > 
<! ELEMENT postcode (#PCDATA)> 
<! ELEMENT market .participant (business | person) > 
Service DTD 

<! ELEMENT service. location (#PCDATA)> 

<! ELEMENT service.terms (#PCDATA)> 

<! ELEMENT service.operation.name (#PCDATA)> 

<! ELEMENT service .operation (service.operation.name, 

service .operation. location, service. operation. input, 

service.operation.output) > 
<! ELEMENT service (service. name, service. location, 

service .operation+, service.terms) > 
<! ELEMENT service .operation. input (#PCDATA)> 
<! ELEMENT service. operation. location (#PCDATA)> 
<! ELEMENT service. name (#PCDATA)> 
<!ELEMENT service .set (service+)> 
<! ELEMENT service.operation.output (#PCDATA)> 
One instance of a document produced according to the 
transact.dtd follows: 
<?xml version="1.0"?> 
<!-- rorder.xml Version: 1.0 --> 
<!-- Copyright 1998 Veo Systems, Inc. --> 
<!DOCTYPE transaction.description SYSTEM "ura:x- 

veosystems:dtd:cbl transact: 1.0:> 
transaction. description transaction. type»"order"> 
<meta> 

<urn?urn:x-veosystems:doc:00023 
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</urn> 

<thread.id party.assigned.by«"reqorg">FRT876 
</thread.id> 
</meta> 

<issuer.pointer> 

<xll.locator urllink="reqorg.xml">Customer 
Pointer 
</xll.locator> 
</issuer.pointer> 
<counterparty.pointer> 

<xli. locator urllink«"compu.xml">Catalog entry 

owner 
pointer 
</xll.locator> 
</counterparty.pointer> 
<exchange.description> 
<line.item> 

<product.instance> 
<product.description.pointer> 

<xll. locator urUink="cthnk.xmr>Catalogue Entry 

Pointer 
</xll. locator > 
</product.description.pointer> 
<product.specifics> 
<info .description. set> 
<info.description> 
<xml.descriptor> 
<doctype> 

<dtd system. id="urn:x-veosystems:dtd:cbl:gp rod: 1.0 

7> 
</doctype> 

<xml.descriptor.details> 

<xll.xptr.frag>DESCENDANT(ALL,os)STRING 
("Windows 95") 
</xll.xptr.frag> 

<xll.xptr.frag>DECENDANT(ALL,p. speed) 

STRING("200") 
</xll.xptr.frag> 

<xll.xptr.frag> DESCENDANT ALL, 

hard.disk.capacity) STRING("4") 
</xll.xptr.frag> 

<xll.xptr.frag>DESCENDANT(ALL,d.size) 

STRING("14.1") 
</xll.xptr.firag> 
</xml.descriptor.details> 
</xml.descriptor> 
</info.description> 
</info.description.set> 
</product.specifics> 
<quantity>l 
</quantity> 

</product.instance> 
<shipment. coordinates. set> 
<shipment.coordinates> 
<shipment.destination> 
<address.set> 
<address.named>SW-l 
</address.named> 
<address.physical> 

<building.sublocation>208C</ 

building.sublocation> 
<location.in.street>123 
</location.in.street> 
<street>Frontage Rd. 
</street> 
<city>Beltway 
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</city> 

<country.subentity.us 

country.subentity.us.name="MD"/> 

<postcode >20000 

</postcode> 
</address.physical> 
<telephone> 

<telephone.number>617-666-2000 

</telephone .number> 

<telephone.extension>1201 

</telephone .extension> 
</telephone> 
</address.set> 
</shipment.destination> 

<shipment.special>No deliveries after 4 PM</ 

shipment.special> 
</shipment.coordinates> 
</shipment.coordinates.set> 

<payment.set> 

<credit.card 

issuer.name="VISA" 

instrument.number="3787-812345-67893" 
expiry.date="12/97" 
currency.code="USD"/> 
<amount.group> 

<amount,monetary currency.code="USD">3975 

</amount.monetary> 
</amount.group> 
</payment.set> 
</line.item> 

</exchange.description> 
</transaction.description> 

Accordingly, the present invention provides a technique 
by which a market participant is able to identify itself, and 
identify the types of input documents and the types of output 
documents with which it is willing to transact business. The 
particular manner in which the content carried in such 
documents is processed by the other parties to the 
transaction, or by the local party, is not involved in estab- 
lishing a business relationship nor carrying out transactions. 

FIG. 3 provides a simplified view of a participant node in 
the network according to the present invention. The node 
illustrated in FIG. 3 includes a network interface 300 which 
is coupled to a communication network on port 301. The 
network interface is coupled to a document parser 301. The 
parser 301 supplies the logical structures from an incoming 
document to a translator module 302, which provides for 
translating the incoming document into a form usable by the 
host transaction system, and vice versa translating the output 
of host processes into the format of a document which 
matches the output document form in the business interface 
definition for transmission to a destination. The parser 301 
and translator 302 are responsive to the business interface 
definition stored in the participant module 303. 

The output data structures from the translator 302 are 
supplied to a transaction process front end 304 along with 
events signaled by the parser 301. The front end 304 in one 
embodiment consists of a JAVA virtual machine or other 
similar interface adapted for communication amongst 
diverse nodes in a network. The transaction processing front 
end 304 responds to the events indicated by the parser 301 
and the translator 302 to route the incoming data to appro- 
priate functions in the enterprise systems and networks to 
which the participant is coupled. Thus, the transaction 
process front end 304 in the example of FIG. 3 is coupled to 
commercial functions 305, database functions 306, other 
enterprise functions such as accounting and billing 307, and 
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to the specific event listeners and processors 308 which are 
designed to respond to the events indicated by the parser. 

The parser 301 takes a purchase order like that in the 
example above, or other document, specified according to 
5 the business interface definition and creates a set of events 
that are recognized by the local transaction processing 
architecture, such as a set of JAVA events for a JAVA virtual 
machine. 

The parser of the present invention is uncoupled from the 

10 programs that listen for events based on the received docu- 
ments. Various pieces of mark-up in a received document or 
a complete document meeting certain specifications serve as 
instructions for listening functions to start processing. Thus 
listening programs carry out the business logic associated 

15 with the document information. For example, a program 
associated with an address element may be code that vali- 
dates the postal code by checking the database. These 
listeners subscribe to events by registering with a document 
router, which directs the relevant events to all subscribers 

20 who are interested in them. 

For example, the purchase order specified above may be 
monitored by programs listening for events generated by the 
parser, which would connect the document or its contents to 
an order entry program. Receipt of product descriptions 

25 within the purchase order, might invoke a program to check 
inventory. Receipt of address information within the pur- 
chase order, would then invoke a program to check avail- 
ability of services for delivery. Buyer information fields in 
the document, could invoke processes to check order history 

30 for credit worthiness or to offer a promotion or similar 
processing based on knowing the identity of the consumer. 

Complex listeners can be created as configurations of 
primitive ones. For example, a purchase order listener may 
contain and invoke the list listeners set out in the previous 

35 paragraph, or the list members may be invoked on their own. 
Note that the applications that the listeners run are unlikely 
to be native XML processes or native JAVA processes. In 
these cases, the objects would be transformed into the format 
required by the receiving trans application. When the appli- 

40 cation finishes processing, its output is then transformed 
back to the XML format for communication to other nodes 
in the network. 

It can be seen that the market participant document type 
description, and the transaction document type description 

45 outlined above include a schematic mapping for logic ele- 
ments in the documents, and include mark-up language 
based on natural language. The natural language mark-up, 
and other natural language attributes of XML facilitate the 
use of XML type mark-up languages for the specification of 

50 business interface definitions, service descriptions, and the 
descriptions of input and output documents. 

The participant module 303 in addition to storing the 
business interface definition includes a compiler which is 
used to compile objects or other data structures to be used by 

55 the transaction process front end 304 which corresponds to 
the logical structures in the incoming documents, and to 
compile the translator 302. Thus, as the business interface 
definition is modified or updated by the participant as the 
transactions with which the participant is involved change, 

60 the translator 302 and parser 301 are automatically kept up 
to date. 

In a preferred system, the set of JAVA events is created by 
a compiler which corresponds to the grove model of SGML, 
mainly the standard Element Structure Information Set 
65 augmented by the "property set" for each element. Interna- 
tional Standard ISO/IEC 10179:1996 (£), Information 
Technology — Processing Languages — Document Style 
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Semantics and Specification Language (DSSSL). Turning the objects, corresponding to all the different kinds of events 

XML document into a set of events for the world to process which can occur. A second kind of object is an Event 

contrasts with the normal model of parsing in which the generator, which monitors activity and generates event 

parser output is maintained as an internal data structure. By objects when something happens. Third, event listeners, 

translating the elements of the XML document into JAVA 5 listen for event objects generated by event generators. Event 

events or other programming structures that are suitable for listeners generally listen to specific event generators, such as 

use by the transaction processing front end of the respective for mouse clicks on a particular window. Event listeners call 

nodes enables rich functionality at nodes utilizing the docu- an "ADD event listener" method on the event generator, 

ments being traded. This model can be adapted to the environment of FIG. 3 in 

Thus, the transaction process front end 304 is able to 10 which the objects are generated in response to parsing and 

operate in a publish and subscribe architecture that enables walking a graph of objects, such as represented by an XML 

the addition of new listener programs without the knowledge document. 

of or impact on other listening programs in the system. Each * The system illustrated in FIG. 5 includes a generic XML 

listener, 305, 306, 307, 308 in FIG. 3, maintains a queue in parser 500. Such parser can be implemented using a standard 

which the front end 304 directs events. This enables multiple 15 call back model. When a parsing event occurs, the parser 

listeners to handle events in parallel at their own pace. calls a particular method in an application object, passing in 

Furthermore, according to the present invention the appli- the appropriate information in the parameters. Thus a single 

cations that the listeners run need not be native XML application 501 resides with the parser. The application 

functions, or native functions which match the format of the packages the information provided by the parser in an XML 

incoming document. Rather, these listeners may be JAVA 20 event object and sends it to as many event listeners as have 

functions, if the transaction process front end 304 is a JAVA identified themselves, as indicated by the block 502. The set 

interface, or may be functions which run according to a of events 502 is completely parser independent. The events 

unique transaction processing architecture. In these cases, 502 can be supplied to any number of listeners and any 

the objects would be transformed into the format required by number of threads on any number of machines. The events 

the receiving application. When the application of the lis- 25 are based on the element structure information set ESIS in 

tener finishes, its output is then transformed back into the one alternative. Thus, they consist of a list of the important 

format of a document as specified by the business interface aspects of a document structure, such as the starts and ends 

definition in the module 303. Thus, the translator 302 is of elements, or of the recognition of an attribute. XML (and 

coupled to the network interface 300 directly for supplying SGML) parsers generally use the ESIS structure as a default 

the composed documents as outputs. 30 set of information for a parser to return to its application. 

The listeners coupled to the transaction processing front A specialized ESIS listener 503 is coupled to the set of 

end may include listeners for input documents, listeners for events 502. This listener 503 implements the ESIS listener 

specific elements of the input documents, and listeners for API, and listens for all XML events from one or more 

attributes stored in particular elements of the input docu- generators. An element event generator 504 is a specialized 

ment. This enables diverse and flexible implementations of 35 ESIS listener which is also an XML event generator. Its 

transaction processes at the participant nodes for filtering listeners are objects only interested in events for particular 

and responding to incoming documents. types of elements. For example in an HTML environment, 

FIG. 4 illustrates a process of receiving and processing an the listener may only be interested in ordered lists, that is 

incoming document for the system of FIG. 3. Thus, the only the part of the document between the <OL> and 

process begins by receiving a document at the network 40 </OL>tags. For another example, a listener may listen for 

interface (step 400). The parser identifies the document type "party.name" elements, or for "service. name" elements 

(401) in response to the business interface definition. Using according to the common business language, from the 

the business interface definition, which stores a DTD for the example documents above, process the events to ensure that 

document in the XML format, the document is parsed (step the elements carry data that matches the schematic mapping 

402). Next, the elements and attributes of the document are 45 for the element, and react according to the process needed at 

translated into the format of the host (step 403). In this the receiving node. 

example, the XML logic structures are translated into JAVA This allows the system to have small objects that listen for 

objects which carry the data of the XML element as well as particular parts of the document, such as one which only 

methods associated with the data such as get and set tunc- adds up prices. Since listeners can both add and remove 

tions. Next, the host objects are transferred to the host 50 themselves from a generator, there can be a listener which 

transaction processing front end (step 404). These objects only listens to for example the <HEAD> part of an HTML 

are routed to processes in response to the events indicated by document. Because of this and because of the highly recur- 

the parser and the translator. The processes which receive sive nature of XML documents, it is possible to write highly 

the elements of the document are executed and produce an targeted code, and to write concurrent listeners. For 

output (step 405). The output is translated to the format of 55 example, an <OL> listener can set up an <LI> listener 

an output document as defined by the business interface completely separate from the manner in which the <UL> 

definition (step 406). In this example, the translation pro- (unordered list) listener sets up its <LI> listener, 

ceeds from the form of a JAVA object to that of an XML Alternatively, it can create a listener which generates a 

document. Finally, the output document is transmitted to its graphic user interface and another which searches a database 

destination through the network interface (step 407). 60 using the same input. Thus, the document is treated as a 

FIG. 5 is a more detailed diagram of the event generator/ program executed by the listeners, as opposed to the finished 

event listener mechanism for the system of FIG. 3. In data structure which the application examines one piece at a 

general the approach illustrated in FIG. 5 is a refinement of time. If an application is written this way, it is not necessary 

the JAVA JDK 1.1 event model. In this model, three kinds of to have the entire document in memory to execute an 

objects are considered. A first kind of object is an event 65 application. 

object which contains information about the occurrence of The next listener coupled to the set of events 502 is an 

an event. There may be any number of kinds of event attribute filter 505. The attribute filter 505 like the element 
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filter 504 is an attribute event generator according to the events 514 from the JAVA walker 512 and translates selected 

ESIS listener model. The listener for an attribute filter ones to present a JAVA object as an XML document. In the 

specifies the attributes it is interested in, and receives events one preferred embodiment, the event generator 515 exploits 

for any element having that attribute specified. So for the JAVA beans API. Each object seen becomes an element, 

example, a font manager might receive events only for 5 with the element name the same as the class name. Within 

elements having a font attribute, such as the <P FONT- mat element, each embedded method also becomes an 

"Times Roman"/P>. element whose content is the value returned by invoking the 

The element event generator 504 supplies such element met hod. If it is an object or an array of objects, then these 

objects to specialize the element listeners 504A. are wa Ux ec j m turn 

The attribute event generator 505 supplies the attribute J(J pjQ 6 outlines a part icular application built on the 

event objects to attribute listeners 505A. Similarly, the framework of na 5 , ^ application takes in an XML 

attribute objects are supplied to a "architecture" in the sense documen t 600 and applies it to a parser/generator 601 . ESIS 

of an SGML/XML transformation from one document type eyents m are generated and supplied t0 an attribute gen . 

to another using attributes. Thus the architecture of 505B erat0f m and ^ buQder m ^ aUribute geaeralor 

allows a particular attribute with a particular name to be a5 corresponds t0 the generator 505 of FIG. 5. It supplies the 

distinguished. Only elements with that attribute defined events tQ tfae « architecture » 5 05B for translating the XML 

become part of the output document, and the name of the m tQ an HTML output for example . events are 

element in the output document is the value of the attribute processed in parallel as indicated by block 605 and pro- 

in the input document. For example, if the architecture 505B cessed by listeners . The output of lhe listeners are supplied 

is HTML, the string: 20 (0 a document wr i ter 506 and then translated back to an 

<PURCHASES HTML="OL"xITEM HTML= xm L format for oulputi for example this application 

"LTxNAME illustrated in FIG. 6 takes an XML document and outputs an 

HTML="B">STUFF</NAMExPRICE HTML document containing a form. The form is then sent 

HTML="B">123</PRICE></ITEM></PURCHASES> to a browser, and the result is converted back to XML. For 

translates into: 25 this exercise, the architecture concept provides the mapping 

<OLxLIxB>STUFF</BxB>123</Bx/LIx/OL> from XML to HTML. The three architectures included in 

which is correct HTML. FIG. 6 include one for providing the structure of the HTML 

The next module which is coupled to the set of events 502 document, such as tables and lists, a second specifying text 

is a tree builder 506. The tree builder takes a stream of XML to be displayed, such as labels for input fields on the browser 

events and generates a tree representation of the underlying 30 document, and the third describes the input fields them- 

document. One preferred version of the tree builder 506 selves. The elements of the XML document required to 

generates a document object model DOM object 507, maintain the XML documents structure become invisible 

according to the specification of the W3C (See, http:// fields in the HTML form. This is useful for use in recon- 

www.w3.org/TR/1998/WD-DOM-19980720/ struction of the XML document from the information the 

introduction.html). However listeners in event streams can 35 client will put into the HTTP post message that is sent back 

be used to handle most requirements, a tree version is useful to the server. Each architecture takes the input document and 

for supporting queries around a document, reordering of transforms it into an architecture based on a subset of 

nodes, creation of new documents, and supporting a data HTML, Listeners listening for these events, output events 

structure in memory from which the same event stream can for the HTML document, which then go to a document 

be generated multiple times, for example like parsing the 40 writer object. The document writer object listens to XML 

document many times. A specialized builder 508 can be events and turns them back into an XML document. The 

coupled to the tree builder 506 in order to build special document writer object is a listener to all the element 

subtrees for parts of the document as suits a particular generators listening to the architectures in this example, 

implementation. The organization of the processing module illustrated in 

In addition to responses to incoming documents, other 45 FIGS. 5 and 6 is representative of one embodiment of the 

sources of XML events 502 can be provided. Thus, an event parser and transaction process front end for the system of 

stream 510 is generated by walking over a tree of DOM FIG. 3. As can be seen, a very flexible interface is provided 

objects and regenerating the original event stream created by which diverse transaction processes can be executed in 

when the document was being parsed. This allows the response to the incoming XML documents, or other struc- 

system to present the appearance that the document is being 50 tured document formats. 

parsed several times. FIG. 7 illustrates a node similar to that of FIG. 3, except 

The idea of an object which walks a tree and generates a that it includes a business interface definition builder module 

stream of events can be generalize beyond the tree of DOM 700. Thus, the system of FIG. 7 includes a network interface 

objects, to any tree of objects which can be queried. Thus, 701, a document parser 702, and a document translator 703. 

a JAVA walker 512 may be an application which walks a tree 55 The translator 703 supplies its output to a transaction 

of JAVA bean components 513. The walker walks over all processing front end 704, which in turn is coupled to 

the publicly accessible fields and methods. The walker keeps listening functions such as commercial functions 705, a 

track of the objects it has already visited to ensure that it database 706, enterprise functions 707, and other generic 

doesn't go into an endless cycle. JAVA events 514 are the listeners and processors 708. As illustrated in FIG. 7, the 

type of events generated by the JAVA walker 512. This 60 business interface definition builder 700 includes a user 

currently includes most of the kinds of information one can interface, a common business library CBL repository, a 

derive from an object. This is the JAVA equivalent of ESIS process for reading complementary business interface 

and allows the same programming approach applied to XML definitions, and a compiler. The user interface is used to 

to be applied to JAVA objects generally, although particu- assist an enterprise in the building of a business interface 

larly to JAVA beans. 65 definition relying on the common business library 

The JAVA to XML event generator 515 constitutes a JAVA repository, and the ability to read complementary business 

listener and a JAVA event generator. It receives the stream of interface definitions. Thus, the input document of a comple- 
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mentary business interface definition can be specified as the 
output document of a particular transaction, and the output 
document of the complementary business interface defini- 
tion can be specified as the input to such transaction process. 
In a similar manner a transaction business interface defini- 
tion can be composed using components selected from the 
CBL repository. The use of the CBL repository encourages 
the use of standardized document formats, such as the 
example schema (bidl) documents above, logical structures 
and interpretation information in the building of business 
interface definitions which can be readily adopted by other 
people in the network. 

The business interface definition builder module 700 also 
includes a compiler which is used for generating the trans- 
lator 703, the objects to be produced by the translator 
according to the host transaction processing architecture, 
and to manage the parsing function 702. 

FIG. 8 is a heuristic diagram showing logical structures 
stored in the repository in the business interface definition 
builder 700. Thus, the repository storage representative 
party business interface definitions 800, including for 
example a consumer BID 801, a catalog house BID 802, a 
warehouse BID 803, and an auction house BID 804. Thus, 
a new participant in an online market may select as a basic 
interface description one of the standardized BIDs which 
best matches its business. In addition, the repository will 
store a set of service business interface definitions 805. For 
example, an order entry BID 806, an order tracking BID 
807, an order fulfillment BID 808, and a catalog service BID 
809 could be stored. As a new participant in the market 
builds a business interface definition, it may select the 
business interface definitions of standardized services stored 
in the repository. 

In addition to the party and service BIDs, input and output 
document BIDs are stored in the repository as indicated by 
the field 810. Thus, a purchase order BID 811, an invoice 
BID 812, a request for quote BID 813, a product availability 
report BID 814, and an order status BID 815 might be stored 
in the repository. 

The repository, in addition to the business interface defi- 
nitions which in a preferred system are specified as docu- 
ment type definitions according to XML, stores interpreta- 
tion information in the form of semantic maps as indicated 
by the field 816. Thus, semantic maps which are used for 
specifying weights 817, currencies 818, sizes 819, product 
identifiers 820, and product features 821 in this example 
might be stored in the repository. Further, the interpretation 
information provides for typing of data structures within the 
logical structures of documents. 

In addition, logical structures used in the composing of 
business interface definitions could be stored in the reposi- 
tory as indicated by block 822. Thus, forms for providing 
address information 823, forms for providing pricing infor- 
mation 824, and forms for providing terms of contractual 
relationships could be provided 825. As the network 
expands, the CBL repository will also expand and standard- 
ize tending to make the addition of new participants, and the 
modification of business interface definitions easier. 

FIG. 9 illustrates the process of building a business 
interface definition using the system of FIG. 7. The process 
begins by displaying a BID builder graphical interface to the 
user (step 900). The system accepts user input identifying a 
participant, service and document information generated by 
the graphical interface (step 901). 

Next, any referenced logical structures, interpretation 
information, document definitions and/or service definitions 
are retrieved from the repository in response to user input via 
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the graphical user interface (step 902). In the next step, any 
complementary business interface definitions or components 
of business interface definitions are accessed from other 
participants in the network selected via user input, by 

5 customized search engines, web browsers or otherwise (step 
903). A document definition for the participant is created 
using the information gathered (step 904). The translators 
for the document to host and host to document mappers are 
created by the compiler (step 905). Host architecture data 

0 structures corresponding to the definition are created by the 
compiler (step 906), and the business interface definition 
which has been created is posted on the network, such as by 
posting on a website or otherwise, making it accessible to 
other nodes in the network (step 907). 

5 Business interface definitions tell potential trading part- 
ners the online services the company offers and which 
documents to use to invoke those services. Thus, the services 
are defined in the business interface definition by the docu- 
ments that they accept and produce. This is illustrated in the 
2Q following fragment of an XML service definition. 
<service> 

<service.name>Order Service </service.name> 
<service.location>www.veosy stems. com/order</ 
service.location> 
25 < service, op > 

<service.op.name>Submit Order</service.op.name> 
<service.op.inputdoowww.commerce.net/po.dtd</ 

service. op. inputdoo 
<service .op .outputdoo 
30 www.veosystems.com/invoice.dtd</ 
service.op .outputdoo 
</service.op> 
<service.op> 

35 <service.op.name>Track Order</service.op.name> 
<se rvice.op.inputdoowww.commerce.net 
/request. track.dtd<service.op.inputdoc> 
<service.op.outputdoc> 
www.veosystems.com/ 
40 response.track.dtd<service .op .outputdoo 

</service,op> 
</service> 

This XML fragment defines a service consisting of two 
transactions, one for taking orders and the other for tracking 

45 them. Each definition expresses a contract or promise to 
carry out a service if a valid request is submitted to the 
specified Web address. The Order service here requires an 
input document that conforms to a standard "po.dtd" Docu- 
ment Type Definition located in the repository, which may 

50 be local, or stored in an industry wide registry on the 
network. If a node can fulfill the order, it will return a 
document conforming to a customized "invoice .dtd" whose 
definition is local. In effect, the company is promising to do 
business with anyone who can submit a Purchase Order that 

55 conforms to the XML specification it declares. No prior 
arrangement is necessary. 

The DTD is the formal specification or grammar for 
documents of a given type; it describes the elements, their 
attributes, and the order in which they must appear. For 

60 example, purchase orders typically contain the names and 
addresses of the buyer and seller, a set of product 
descriptions, and associated terms and conditions such as 
price and delivery dates. In Electronic Data Interchange EDI 
for example, the X12 850 specification is a commonly used 

65 model for purchase orders. 

The repository encourages the development of XML 
document models from reusable semantic components that 
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are common to many business domains. Such documents 
can be understood from their common message elements, 
even though they may appear quite different. This is the role 
of the Common Business Library repository. 

The Common Business Library repository consists of 5 
information models for generic business concepts including: 

business description primitives like companies, services, 
and products; 

business forms like catalogs, purchase orders, and 
invoices; 

standard measurements, date and time, location, classifi- 
cation codes. 

This information is represented as an extensible, public 
set of XML building blocks that companies can customize 15 
and assemble to develop XML applications quickly. Atomic 
CBL elements implement industry messaging standards and 
conventions such as standard ISO codes for countries, 
currencies, addresses, and time. Low level CBL semantics 
have also come from analysis of proposed metadata frame- 2Q 
works for Internet resources, such as Dublin Core. 

The next level of elements use these building blocks to 
implement the basic business forms such as those used in 
XI 2 EDI transactions as well as those used in emerging 
Internet standards such as OTP (Open Trading Protocol) and 25 
OBI (Open Buying on the Internet). 

CBL's focus is on the functions and information that are 
common to all business domains (business description 
primitives like companies, services, and products; business 
forms like catalogs, purchase orders, and invoices; standard 3Q 
measurements, date and time, location, classification codes). 
CBL builds on standards or industry conventions for seman- 
tics where possible (e.g., the rules that specify "day/month/ 
year" in Europe vs "month/day/year" in the U.S. are 
encoded in separate CBL modules). 35 

The CBL is a language that is used for designing appli- 
cations. It is designed to bridge the gap between the "docu- 
ment world" of XML and the "programming world" of JAVA 
or other transaction processing architectures. Schema 
embodies a philosophy of "programming with documents" 4Q 
in which a detailed formal specification of a document type 
is the master source from which a variety of related forms 
can be generated. These forms include XML DTDs for CBL, 
JAVA objects, programs for converting XML instances to 
and from the corresponding JAVA objects, and supporting 45 
documentation. 

The CBL creates a single source from which almost all of 
the pieces of a system can be automatically generated by a 
compiler. The CBL works by extending SGML/XML, which 
is normally used to formally define the structures of par- 5Q 
ticular document types, to include specification of the 
semantics associated with each information element and 
attribute. The limited set of (mostly) character types in 
SGML/XML can be extended to declare any kind of 
datatype. 55 

Here is a fragment from the CBL definition for the 
"datetime" module: 

<!-- datetime.mod Version: 1.0 --> 

<!-- Copyright 1998 Veo Systems, Inc. --> 

60 

<! ELEMENT year (#PCDATA)> 
<! AITUST year 
schema CD ATA #FIXED "urn:x- 
veosystems:stds:iso:8601:3.8" 
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<! ATTLIST month 
schema CD ATA #FIXED 
veosystems:stds:iso:8601:3.12" 



urn:x- 



65 



<! ELEMENT month (#PCDATA)> 



In this fragment, the ELEMENT "year" is defined as 
character data, and an associated "schema" attribute, also 
character data, defines the schema for "year 1 ' to be section 
3.8 of the ISO 8601 standard. 

This "datetime" CBL module is in fact defined as an 
instance of the Schema DTD. First, the module name is 
defined. Then the "datetime" element "YEAR" is bound to 
the semantics of ISO 8601: 

<! DOCTYPE SCHEMA SYSTEM "schema.dtd"> 

<SCHEMA><Hl>Date and Time Module</Hl> 

<ELEMNTTYPE NAMEo"year" DATATYPE- 
"YEAR"xMODEL> 
<STRING 

DATATYPE="YEAR"x/STRINGx/MODEL> 
<ATTDEF NAME=:schema:iso8601" DATATYPE= 

"CD ATA" > 

<FIXED>3.8 

Gregorian calendar</FIXEDx/ATTDEF></ 
ELEMENTTYPE> 

The example market participant and service modules 
above are also stored in the CBL repository. 

In FIG. 10, an Airbill 1000 is being defined by custom- 
izing a generic purchase order DTD 1001, adding more 
specific information about shipping weight 1002. The 
generic purchase order 1001 was initially assembled from 
the ground up out of CBL modules for address, date and 
time, currency, and vendor and product description. Using 
CBL thus significantly speeds the development and imple- 
mentation of XML commerce applications. More 
importantly, CBL makes it easier for commercial applica- 
tions to be interconnected. 

In the CBL, XML is extended with a schema. The 
extensions add strong-typing to XML elements so that 
content can be readily validated. For example, an element 
called <CPU_clock_speed> can be defined as an integer 
with a set of valid values: {100, 133, 166, 200, 233, 266 
Mhz.}. The schema also adds class-subclass hierarchies, so 
that information can be readily instantiated from class 
definitions. A laptop, for instance, can be described as a 
computer with additional tags for features such as display 
type and battery life. These and other extensions facilitate 
data entry, as well as automated translations between XML 
and traditional Object-Oriented and relational data models. 

Thus the completed BID is run through the compiler 
which produces the DTDs for the actual instance of a 
participant and a service as outlined above, the JAVA beans 
which correspond to the logical structures in the DTD 
instances, and transformation code for transforming from 
XML to JAVA and from JAVA to XML. In alternative 
systems documentation is also generated for display on a 
user interface or for printing by a user to facilitate use of the 
objects. 

For the example market participant and service DTDs set 
forth above, the JAVA beans generated by the compiler are 
set forth (with some redactions for conciseness) as follows: 
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import corn.veo.vsp.doclet.mela.Document; 
public class Address Physical extends Document { 

public static final String DOC_TVTE « "address.physical"; 

String mStreet; 

String mCity; 
public final static int AK - 0; 
public final static int AL - 1; 
public final static int AR - 2; 
public final static int AZ = 3; 
public final static int CA = 4; 

public final static int WI = 48; 
public final static int WV - 49; 
public final static int WY = 50; 

int mState; 

String mPostcode; 
public final static int AD - 51; 
public final static int AB = 52; 
public final static int AF - 53; 
public final static int AG = 54; 
public final static int AI = 55; 
public final static int AM = 56; 

int mCountry; 

public AddressPhysical( ){ 

super(DOC_TYPE); 
mStreet = new String( ); 
mCity = new String( ); 

this.mState - -1; 
mPostcode = null; 

this.mCountry - -1; 

} 

public Address Physical(String doc_type) { 

super(doc_type); 
mStreet - new String( ); 
mCity = new String( ); 

this.mState = -1; 
mPostcode = null; 

this.mCountry = -1; 

} 

static public AddressPhysical initAddressPhysical(String iStreet,String iCity,int 
iState, String iPostcode,int iCountry){ 

AddressPhysical obj - new AddressPhysical( ); 
obj.initiaiizeAll(iStrcct, iCity, iState, iPostcode, iCountry); 
return obj; 

} 

public void initialize All (String iStreet,String iCity,int iState, String iPostcode,int 
iCountry){ 

mStreet « iStreet; 
mCity = iCity; 
mState - iState; 
mPostcode - iPostcode; 
mCountry = iCountry; 

} 

public String getStreet( ){ 
return mStreet; 

} 

public String getStreetToXML( ){ 

if (getStreet( ) — null) return null; 
char [ ]c = getStreet( ).toCharArray( ); 
StringBuffer sb - new StringBufEer( ); 
for (int x - 0; x < c. length; x++){ 
switch(c[xD{ 
case'>': 
sb.append(">"); 
break; 
case'<': 
sb.append("<"); 
break; 
case '&': 
sb.append("&"); 
break; 
case"""; 
sb.append("""); 
break; 
case "V 
sb.append("""); 
break; 
default: 
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if (Character.isDefined(c[x])) 
sb.append(c[xj); 

} 

} 

return sb.toString( ); 

} 

public void setStreet(String inp) { 
this.mStreet - inp; 

} 

public void streetFromXML(String n){ 
sctStreet(n); 

} 

public String getCity( ){ 
return mCity; 

} 

public String getCityToXML( ){ 

if (get City ( ) — null) return null; 
char [ ] c = getCity( ).toChar Array ( ); 
StringBufTer sb = new StringBuffer( ); 
for (intx= Opt < c.length;x++){ 
switch(c[x]){ 
case '>': 
sb. append (">"); 
break; 
case '<': 
sb.append("<"); 
break; 
case '&': 
sb .append(" & ") ; 
break; 
case 

sb.append("""); 

break; 
case "V*: 

sb.appcnd("""); 

break; 
default: 

if (Character. isDefined(c[x])) 
sb.append(c(x]); 

} 

} 

return sb.toString( ); 

} 

public void setCity (String inp) { 
this.mCity = inp; 

} 

public void cityFromXML (String n){ 
setCity(n); 

} 

public int getState( ){ 
return mState; 

} 

public String getStateToXML( ){ 
switch (mState) { 

case AK return "AK", 
case AL return "AL", 
case AR return "AR"; 
case AZ return "AZ", 

} 

return null; 

> 

public void setState(int inp){ 
ihis.mSLate = inp; 

} 

public void stateFromXML(String s){ 

if(s.equals("AK"))mState «. AK; 
else if (s. equal s("AL"))mState - AL, 
else if (s. equal s("AR"))mState ■» AR, 
else if (s. equal s("AZ")) mState - AZ, 

} 

public String getPostcode( ){ 
return mPostcode; 

} 

public String getPostcodeToXML( ){ 

if (getPostcode( ) — null) return null; 
char [ ]c - getPostcode( ).toChar Array ( ); 
StringBufTer sb - new StringBuffer( ); 
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for (int x = 0; x < clength; x++){ 
switch(c[x]){ 
case V: 

sb.append(">"); 

break; 
case '<': 

sb.append("<"); 

break; 
case '&': 

sb.append("&"); 

break; 
case 

sb. append ( w & quo t;"); 

break; 
case "\": 

sb.append("""); 

break; 
default: 

if (Character.isDefined(c{x])) 

sb.append(c[x]); 

} 

} 

return sb.toString( ); 

} 

public void setPostcode (String inp) { 
this.mPostcode = inp, 

} 

public void PostcodeFromXMLfString n){ 

se (Postcode (n); 
public int getCountry( ){ 
return mCountry; 

} 

public String getCountryToXML( ){ 
switch (mCountry){ 

case AD: return "AD"; 
case AE return "AE" 
case AF: return "AF", 

} 

return null; 

} 

public void setCountry(int inp) { 
this.mCountry - inp; 

} 

public void countryFromXML(String s){ 

if (s.equals(" AD")) mCountry » AD; 
else if (s. equal s("AE")) mCountry «- AE; 
else if (s. equal s("AF")) mCountry « AF; 
else if (s. equals ("AG")) mCountry o AG; 
else if (s. equal s("AI"))mCountry » AI; 

} 

} 

package com.veo.xdk.dev.sche ma. test.blib; 
import com . veo . vsp.docle t. meta . Docume nt; 
public class AddressSet extends Document { 

public static final String DOC_TYPE - "address.set"; 
AddressPhysical mAddress Physical; 
String [ ] mTelephone; 
String [ ] mFax; 
String [ ] mEmail; 
String [ ] mlnternet; 
public Address Set( ){ 

super(DOC_TYPE); 

this.mAddressPhj'sical = new AddressPhysical( ); 
mTelephone • null; 
mFax = null; 
mEmail = null; 
mlnternet = null; 

} 

public Address Set(String doc_type){ 
super(doc_type); 

lhis.mAddressPhysical = new AddressPhysical( ); 
mTelephone = null; 
mFax = null; 
mEmail » null; 
mlnternet - null; 

} 

static public AddressSet initAddressSet(AddressPhysical iAddressPhysica^String [ ] 
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iTelephone,String [ ] iFax,String [ ] iEmail,String [ ] ilntcrnet){ 
AddressSet obj = new AddressSet( ); 

obj initializeAlKiAddressPhysical, iTclephone, iFax, iEmail, ilnternet); 
return obj; 

public void initializeAll(AddressPhysicat iAddressPhysical.String [ ] iTelephone,String [ ] 
iFax,String [ ] iEmail, String [ ] ilnternet){ 

mAddressPhysical » lAddrcssPhysical; 
mTelephone = iTelephone; 
mFax - iFax; 
mEmail = iEmail; 
mlnternet « ilnternet; 

public Address Physical getAddressPhysical( ){ 
return mAddressPhysical; 

public void setAddressPhysical(AddressPhysical inp) { 
this. mAddressPhysical » inp; 

} 

public Siring [ ] getTelephone( ){ 
return mTelephone; 

} 

public String getTelephone(tnt index) { 
if (this.mTelephone ™ null) 
return null; 

if (index >» this.mTelephone. length) 
return null; 

if (index < 0 && -index > this. mTelephone. length) 
return null; 

if (index >= 0) return this.mTelephone[index]; 

return thU.mTelephone[this.mTelephone. length + index]; 

} 

public String [ j getTelephoneToXML( ){ 

String [ ] valArr - getTelephone( ); 
if (valArr « null) return null; 
String [ ] nvArr = new String[valArr.length]; 
for (int z = 0; z < nv An. length; z++){ 
char [ ] c - valArr[z].toCharArray( ), 
StringBuffer st = new StringBuffer( ), 
StringBuffer sb = new StringBu£fer( ), 
for (int x = 0; x < c. length; x++){ 
switch(c(x]){ 
case *>': 
sb.append(">"); 
break; 
case '<': 
sb.append("<'*); 
break; 
case '&': 
sb.append("&"); 
break; 
case 

sb.append("""); 
break; 
case 

sb.append(""'*); 
break; 
default: 
if (Character.isDefined(c[xD) 
sb.append(c[x]); 

} 

} 

nvArr[z] - sb.toString( ); 

} 

return nvArr, 

} 

public void setTelep hone (int index, String inp){ 
if (this.mTelephone «» null) { 
if(index< 0) { 

this.mTelephone - new String! 1]; 

this.mTelephone[0] = inp; 
} else { 

this.mTelephone = new Stringf index + 1 J 
tbis.mTelephone[index] » inp; 

} 

} else if (index < 0) { 

String [ ] newTelephone - new String[this.mTelep hone. length + 1]; 
java.lang.System.arraycopy((Object)mTelephone, 0, 
(Object)newTelephone, 0, this. mTelephone. length); 
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newTelep ho ne[newTelephonc. length - 1] = inp; 
mTclephone » newTelep hone; 
} else if (index >» this.mTelephone.leDgth) { 

String [ ] newTelep hone = new String[index + 1]; 
java.lang.System.arraycopy((Object)mTelephone > 0, 
(Object)newTelephone, 0, this.mTelephone.length); 

newTelep ho ne[index] - inp; 
mTelephone - newTelephonc; 

} else { 

this. mTelephone[ index] «» inp; 

> 

} 

public void setTelephone (String [ ] inp) { 
this. mTelephone = inp; 

public void telephoneFromXML(String n){ 
setTelephone(-l, n); 

} 

public String [ ] getFaxf ){ 
return mFax; 

} 

public String getFax(int index) { 
if (this.inFax ~ null) 
return null; 

if (index >- this. mFax. length) 
return null; 

if (index < 0 && -index > this. mFax .length) 
return null; 

if (index >» 0) return this.mFax[index]; 
return th is. mFax[this. mFax. length + index]; 

} 

public String [ ] getFaxToXML( ){ 

String [ ] valArr - getFax( ); 
if (valArr null) return null; 
String [ ] nvArr - new String[valArr.length]; 
for (int z," 0; z < nv An. length; z++){ 
char [ ] c ■» valArr[z].toCharArray( ); 
StringBuffer st - new StringBuffer( ); 
StringBuffer sb = new StringBuffer( ); 
for (int x = 0; x < c.length; x++){ 
switch(c[x]) { 
case *>': 
sb.append(">"); 
break; 
case '<': 
sb.append("<"); 
break; 
case '&': 
sb.appe nd( M &a mp; ") ; 
break; 
case 

sb.append("""); 
break; 
case 

sb.append("""); 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.appe nd(c[x]); 

} 

} 

nvArrfz] - sb.toString( ); 

> 

return nvArr, 

} 

public void setFax(int index, String inp){ 
if (this. mFax null) { 
if(index < 0) { 
this.mFax - new String[l]; 
this.mFax[0] - inp; 
} else { 

this.mFax - new String[indcx + 1]; 
this.mFaxI index] - inp; 

} 

} else if (index < 0) { 

String [ ] newFax - new String(this. mFax. length + 1]; 
java.lang.System.arraycopy((Object)mFax > 0, (Object) newFax, 0, 

this mFax.length); 

newFaxf ne wFax. length 1] - inp; 
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mFax = new Fax; 
} else if (index >*» this.mFax.length){ 

String [ ] newFax = new Stringfindex + 1]; 
java.lang.System.arraycopy((Object)mFax, 0, (Object) newFax, 0, 

this.mFax.length); 

newFax[ index] = inp; 
mFax - newFax; 

} else { 

this. mFax[ index] - inp; 

} 

} 

public void setFax(String [ ] inp){ 
this.mFax » inp; 

} 

public void faxFroinXML(String n){ 
setFax(-l, n); 

} 

public String [ ] getEmaiI( ){ 
return mEmail; 

} 

public String getEmail(int index){ 
if (this.Email = null) 

return null; 
if (index >= this. mEmail. length) 

return null; 

if (index <0 && -index > this.mEmail.length) 

return null; 
if (index >= 0) return this.mEmail[index]; 
return this.mEmaU[this.mEmail. length + index]; 

} 

public String [ ] getEmailToXML( ){ 

String [ ] valArr - getEmail( ); 
if (valArr -« null) return null; 
String [ ] nvArr - new String[valArr.Iength]; 
for (int z - 0; z < nvArr. length; z++){ 
char [ ] c - valArr[z].toCharArray( ); 
StringBuffer st - new StringBufier( ); 
StringBuffer sb - new StringBuffer( ); 
for (int x = 0; x < clength; x++){ 
switch(c[x]){ 
case '>': 
sb.append(">"); 
break; 
case '<': 
sb. append("<"); 
break; 
case '&': 
sb.append("&"); 
break; 
case""": 
sb . appe nd(" "") ; 
break; 
case"": 
sb .appe nd( w "") ; 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArr[z] » sb.toString( ); 

} 

return nvArr; 

} 

public void setEmail(int index, String inp){ 
if (this. mEmail null) { 
if(index < 0) { 

this.mEmail = new String[l]; 
this.mEmail[0] » inp; 
} else { 

this.mEmail = new String[index + lj 
this. mEmail[ index] = inp; 

} 

} else if (index < 0) { 

String [ ] newEmail = new String! this. mEmail. length + 1]; 
java.lang.System.arraycopy((Object)mEmai], 0, (Object)newEmail, 0, 

this mEmail.length); 

newEmail[newEmaiUength - 1] - inp; 
mEmail - newEmail; 
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} else if (index >= this.mEmaiUength){ 

String [ ] newEmail = new String! index + It 
javaJang.System.arraycopy((Object)mEmaiJ > 0, (Object) newEmail, 0, 

this mEmail.length); 

newEmail[ index] - inp; 
mEmail = newEmail; 

} else { 

this.mEmaiI[index] - inp; 

} 

} 

public void setEmail (String [ ] inp){ 
this. mEmail » inp; 

' } 

public void email FromXML(String n){ 
setEmail(-l, n); 

} 

public String [ ] getlnternet( ){ 
return m Internet; 

} 

public String getlnternet(int index){ 
if (this.m Internet = null) 

return null; 
if (index >= this, mlnternet. length) 

return null; 

if (index < 0 && -index > this.mlnterneLlength) 

return null; 
if (index >= 0) return this.mlnternet[index]; 
return this. mlnternet[ this, mlnternet. length + index]; 

} 

public String [ ] getInternetToXML( ){ 

String [ ] valArr = getinternet( ); 
if (valArr == null) return null; 
String [ ] nvArr - new Stringf valArr. length]; 
for (int z - 0; z < nvArr. length; z++){ 
char [ ] c • valArr[z].toCharArray( ); 
StringBuffer st = new StringBuffer( ); 
StringBuffer sb • new StringBuffer( ); 
for (int x - 0; x < c.Iength; x++){ 
switch(c[x]){ 
case *>': 
sb.append(">"); 
break; 
case '<*: 
sb.appcnd(**«felt;"); 
break; 
case '&*: 
sb ,ap pend(" & "); 
break; 
case""": 
sb.append("""); 
break; 
case 

sb.appcnd("""); 
break; 
default: 
if (Character.isDefined(c{xD) 
sb.append(cfxj); 

} 

} 

nvArijz] = sb.toString( ); 

} 

return nvArr; 

} 

public void setlnternet(int index, String inp){ 
if(this.mlnternet »» null) { 
if(index < 0) { 

this, mlnternet = new StringflJ 
this.mlntemet[0] - inp; 
} else { 

this.mlnternet - new String[index + 3 J 
this. mlntcraet[ index] = inp; 

} 

} else if (index < 0) { 

String [ ] newlnternet = new Stringf this, mlnternet. length + 1]; 
java.lang.System.arraycopy((Object)mInternet, 0, (Object)newInternet, 

0, this. mlnternet. length); 

newlnternet[newlnternet.length - 1] » inp; 
mlnternet - newlnternet, 
} else if (index >- this.mlnternetlength){ 
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String [ ] newlnternet » new String[ index + 1 J 
java.lang.System.arraycopy((Object)m Internet, 0, (Object) newlnternet, 

0, this. m Internet. length); 

ne win ternet[ index] - inp; 
mlnternet * newlnternet; 

} else { 

this.mlnternet[index] - inp; 

}. 

} 

public void setInternet(String [ ] inp){ 
this. mlnternet - inp; 

} 

public void internetFromXML(String n){ 
setlnternet(-l, n); 

} 

} 

package com. veo .xdk. de v.schema. test.b lib ; 
iraport com. veo. vsp.doclet.meta. Document; 
public class Business extends Party { 

public static final String DOC_TYPE - "business"; 

String aBusiness Number; 

public Business( ){ 

super(DOC_TYPE); 

aBusiness Number = new String( ); 

> 

public Business(String doc_type){ 

super(doc_type); 
aBusiness Number = new String( ); 
} 

static public Business intBusiness(String iBusinessNumber,String [ ] 
iPartyName,AddressSet iAddressSet){ 

Business obj = new Business( ); 

obj.initializeAIl(iBusinessNumber, iPartyName, iAddressSet); 
return obj; 

} 

public void initialize All (String iBusinessNumber,String [ ] iPartyName,AddressSct 
iAddressSet) { 

aBusinessNumber = iBusiness Number; 
super, initialize All (iPartyName, iAddressSet); 

} 

public String getBusinessNumber( ) { 
return aBusinessNumber; 

} 

public String getBusinessNumberToXML( ){ 

if (getBusinessNumber( ) »» null) return null; 
char [ ] c = getBusinessNumber( ).toCharArray( ); 
StringBuffer sb = new StringBuffer( ); 
for (int x - 0; x < c. length; x++){ 

switch(c[x]) { 

case V: 

sb.append(">"); 

break; 
case «': 

sb.append("&It;"); 

break; 
case '&*: 

sb.append(" & "); 

break; 
case""": 

sb .appe nd(" "") ; 

break; 
case "\": 

sb.append( u ""); 

break; 
default: 

if (Character.isDefined(c(x])) 

sb.append(c[x]); 

} 

} 

return sb.toString( ); 

} 

public void sctBusinessNumber(String inp){ 
this.aBusinessNumber » inp; 

} 

public void businessNumberFromXML(String n){ 
set Business Number (n) ; 

} 

} 

import com. veo .vsp.doclet.meta. Document; 
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public class Party extends Document { 

public static final String DOC_TYPE - "party"; 
String [ ] mPartyName; 
AddressSet mAd dress Set; 
public Party( ){ 

super(DOC_TYPE); 
mPartyName - new String[0]; 

this.mAddressSet » new AddressSet( ); 

} 

public Party(String doc_type){ 

super(doc_type); 
mPartyName = new String[0]; 

this.mAddressSet = new AddressSet( ); 

} 

static public Party initPartyfString [ ] iPartyName^AddressSet iAddressSet){ 

Party obj - newParty( ); 

obj.initializeAll(iPartyName, iAddressSet); 

return obj; 

} 

public void initializeAll(String [ ] iPartyName,AddressSet iAddressSet) { 
mPartyName = iPartyName; 
mAddressSet » iAddressSet; 

} 

public String [ ] getPartyName( ){ 
return mPartyName; 

} 

public String getPartyName(int index) { 
if(this. mPartyName = null) 
return null; 

if (index >= this. mPartyName. length) 
return null; 

if (index < 0 && -index> this. mPartyName. length) 
return null; 

if (index >- 0) return this. mPartyName[ index]; 

return this.mPartyName[this.mPartyName. length + index]; 

} 

public String [ ] getPartyNameTbXML( ){ 

String [ ] valArr = getPartyName( ); 
if (valArr == null) return null; 
String [ ] nvArr = new String[valArr.length]; 
for (int z = 0; z < nvArr. length; z++){ 
char [ ] c = valArr[z].toCharArray( ); 
StringBuffer st - new StringBuffer ( ); 
StringBuffer sb - new StringBuffcr( ); 
for (int x » 0; x < c.length; x++){ 
switch(c[x]) { 
case '>': 
sb.append(">"); 
break; 
case '<*: 
sb.append("<"); 
break; 
case '&': 
sb.append("&'*); 
break; 
case """: 
sb.append("""); 
break; 
case 

sb.append(**""); 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArr[z] - sb.toString( ); 
} 

return nvArr, 

> 

public void setParty Name (int index, String inp){ 
if(this.mPartyName ==null) { 
if(index < 0) { 

this. mPartyName = new Stringfl]; 
this.mPartyName[0] = inp; 
} else { 

this. mPartyName - new String[ index +1]; 
this.mPartyName[index] - inp; 

} 
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} else if (index < 0) { 

String [ ] newPartyName - new Stiing[ this, m Party Name, length + 1]; 
java.lang.System.arraycopy((Object)m Party Name, 0, 
(Object)newPartyName, 0, this. mPartyName. length); 

newPartyName[newPartyName. length - 1] = inp; 
mPartyName = newPartyName; 
} else if (index >- this.mPartyName.length){ 
String [ ] newPartyName = new String[ index + lj, 
java.lang.System.array cop y((Object) mPartyName, 0, 
(Obj ecQnewParty Name, 0, this. mPartyName. length); 

newPartyName[index] « inp; 
mPartyName = newPartyName; 

} else { 

this. mPartyName[ index] = inp; 

} 

} 

public void setPartyName(String [ ] inp){ 
this. mPartyName « inp; 

} 

public void Party NameFromXML(String n){ 
setPartyName(-l, n); 

} 

public AddressSet getAddressSet( ){ 
return mAddressSet; 

} 

public void setAddressSet( AddressSet inp){ 
this.m AddressSet = inp; 

} 

} 

package com.veo.xdk.dev.schema.test.blib; 
import com.veo.vsp.doclet.meta.Document; 
public class Person extends Party { 

public static final String DOC_TYPE - "person"; 

String aSSN; 
public Person( ){ 

super(DOC_TYPE); 
aSSN = null; 
} 

public Person(String doc type){ 

super(doc_type); 
aSSN = null; 
} 

static public Person initPerson(String iSSN,String [ ] iPartyName,AddressSet 
iAddressSet){ 

Person obj = new Person( ); 

obj. initialize All (iSSN, iParty Name, iAddressSet); 

return obj; 

} 

public void initialize All (String iSSN, String [ ] iParty Name AddressSet iAddressSet) { 
aSSN - iSSN; 

super, initialize All (iParty Name, iAddressSet); 

} 

public String getSSN( ){ 
return aSSN; 

} 

public String getSSNTbXML( ){ 

if (getSSN( ) ~ null) return null; 
char [ ] c = getSSN( ).toChar Array ( ); 
StringBuffer sb = new StringBuffer( ); 
for (int x = 0; x < c. length; x++){ 
switch(c[xj){ 
case '>': 
sb .appe nd(" >") ; 
break; 
case '<': 
sb.append^<"); 
break; 
case 

sb.append("&"); 
break; 
case 

sb.append( u ""); 

break; 
case "\": 

sb .append(" &quo t; '*) ; 

break; 
default: 

if (Character.isDefined(c[x])) 

sb.append(c[x]); 
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} 

} 

return sb.toString( ), 

> 

public void setSSN(String inp){ 
this.aSSN - inp, 

} 

public void sSNFromXML(String n){ 
sctSSN(n); 

} 

} 

package com.veo.xdk.dev.schema.test.blib, 
import com.veo.vsp.doclet.meta. Document; 
public class PrototypeService extends Document { 

public static final String DOC„TYPE » "prototype .service"; 
String mServiceName; 
String [ ] mServiceTerms; 
String [ ] mServiceLocation; 
ServiceOperation [ ] mServiceOperation; 
public PrototypeService( ){ 

super(DOC_TYPE); 
mServiceName « new String( ); 
mServiceTerms = new StringfO]; 
mServiceLocation = new String[0]; 

this.mServiceOperation - new ServiceOperation[0]; 

} 

public PrototypeService (String doc_type){ 

super(doc_type); 
mServiceName » new String( ); 
mServiceTerms » new StringfO]; 
mServiceLocation = new String[0}; 

this.mServiceOperation = new ServiceOperation[0]; 

} 

static public PrototypeService initPrototypeService (String iServiceName,String [ ] 
iServiceTerms,String [ ] iServiceLocation,ServiceOperation [ ] iServiceOperation) { 

PrototypeService obj = new PrototypeService( ); 

obj. initialize All(iServiceName, iServiceTerms, iService Location, 
iServiceOperation); 

return obj; 

} 

public void initialize All (String iServiceName,String [ ] iServiceTerms,String [ ] 
!ServiceLocation,ServiceOpe ration [ ] iServiceOperation) { 
mServiceName - iServiceName; 
mServiceTerms *» iServiceTerms; 
mServiceLocation = iServiceLocation; 
mServiceOperation = iServiceOperation; 

} 

public String getServ ice Name ( ){ 
- return mServiceName; 
} 

public String getServiceNameToXML( ){ 

if (getServiceName( ) null) return null; 
char f ] c - getScrviccName( ).toCharArray( ); 
StringBuffer sb « new StringBufferf ); 
for (int x = 0; x <c, length; x++){ 

switch(c[xD{ 

case 

sb.append(**>"); 

break; 
case *<': 

sb.append("<"); 

break; 
case '&*: 

sb .appe nd(" & "); 

break; 
case : 

sb.append("""); 

break; 
case "\": 

sb.append("""); 

break; 
default: 

if (Character.isDefmed(c(x])) 

sb.append(c[x]); 

} 

} 

return sb.toString( ); 

} 

public void setServiceName(String inp) { 
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this.mServiceName = inp; 

public void serviceNameFromXML(String n){ 
setServiceName(n); 

public String [ ] getServiceTerms( ){ 
return mServiceTerms; 

} 

public String getServiceTerms(int index){ 
if (this.mServiceTenns — null) 

return null; 
if (index >« this. mServiceTerms .length) 

return null; 

if (index < 0 && -index > this. mServiceTerms. length) 
return null; 

if (index >- 0) return this. mServiceTerms [index]; 

return this.mServiceTerms[this. mServiceTerms. length + index]; 

} 

public String [ ] getServiceTermsToXML( ){ 

String [ ] valArr = getServiceTerms( ); 
if (valArr == null) return null; 
String [ ] nvArr = new String[valArr.length]; 
for (int z = 0; z < nv An. length; z++){ 
char [ ] c «> valArr[z].toCharArray( ); 
StringBuffer st - new StringBuffer ( ); 
StringBuffer sb = new StringBufferf ); 
for (int x = 0; x < c. length; x++){ 
switch(c[x]) { 
case '>*: 
sp.append(">"); 
break; 
case "<": 
sb.append("<"); 
break; 
case '&': 
sb.append("&"); 
break; 
case " H ": 
sb . appe nd(" &quo t;") ; 
break; 
case "": 
sb.append("""); 
break; 
default: 
if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArrfz] = sb.toString( ); 
} 

return nvArr; 

} 

public void sctServiceTerms(int index, String inp){ 
if (this. mServiceTerms == null) { 
if(index < 0) { 

this. mServiceTerms = new String[l]; 
this.mServiceTerms[0] - inp; 
} else { 

this. mServiceTerms m new String[index + 1]; 
this.mServiceTerms[index] = inp; 

} 

} else if (index < 0) { 

String [ ] newServiceTerms = new Stringf this. mServiceTenns. length + 

It 

java.lang.System.arraycopy((Object)mServiceTerms, 0, 
(Objec^newServiceTerms, 0, this.mServiceTerms.length); 

newServiceTerms[newServiceTerms.length - 1] » inp; 

mServiceTerms = newServiceTerms; 
} else if (index >= this. mServiceTerms. length) { 

String [ ] newServiceTerms - new String[index + 1]; 

java.Iang.System.arraycopy((Object)mServiceTerms, 0, 
(Object)newServiceTerms, 0, this.mServiceTerms.length); 

newServiceTerms[ index] = inp; 

mServiceTerms = newServiceTerms; 

} else { 

this. mServiceTerms[ index] *> inp; 

} 

} 

public void setServiceTenns(String [ ] inp){ 
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this.mServiceTenns - inp; 

public void ServiceTermsFromXML(String n){ 
setServiceTerms(-3, n); 

} 

public String [ ] getServiceLocation( ){ 
return mServiceLocation; 

} 

public String getScrvicc Location (int indcx){ 
if (this. mServiceLocation M null) 
return null; 

if (index >= this. mServiceLocation. length) 
return null; 

if (index < 0 && -index > this.mServiceLocation.length) 
return null; 

if (index >- 0) return this.mServiceLocation[index]; 

return this. mScrviccLocation[th is. mServiceLocation. length + index]; 

} 

public String [ ] getServiceLocationToXML( ){ 

String [ ] valArr = getServiceLocationf ); 
if (valArr — null) return null; 
String [ ] nvArr «» new String(valArr.Iength]; 
for (int z - 0; z < nvArr. length; z++){ 
char [ ] c = valArr[z].toCharArray( ); 
StringBuffer st - new StringBuffer( ); 
StringBuffcr sb - new StringBuffer( ); 
for (int x o 0; x < c.length; x++){ 
switch(c[x]) { 
case *>': 
sb.appendC>"); 
break; 
case '<': 
sb.append("<"); 
break; 
case '&': 
sb.append("&"); 
break; 
case 

sb.append(**""); 
break; 
case 

sb.append( M ""); 
break; 
default: 
if (Charactcr.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

nvArrjz] » sb.toString( ); 
} 

return nvArr, 

} 

public void setScrviceLocation(int index, String inp){ 
if (this.mServiceLocation » null) { 
if(index < 0) { 

this.mServiceLocation = new String[]]; 
this.mServiceLocation[0] = inp; 
} else { 

this.mServiceLocation = new String[index + 1]; 
this. mServiceLocation[ index] = inp; 

} 

} else if (index < 0) { 

String [ ] newService Location = new 
Stringf this.mServiceLocation. length +1]; 

java.Iang.System.arraycopy((Object)mServiceLocation > 0, 
(Object) newServiceLocation, 0, this.mServiceLocation. length); 

newServiceLocation[newServiceLocation.length - 1] = inp; 

mServiceLocation = newServiceLocation; 
} else if (index >- this.inServiceLocation.length){ 

String [ ] newServiceLocation - new String[index + 1]; 

java.lang.System.arraycopy((Object)mScrviccLocation, 0, 
(Object)newServiceLocation, 0, this.mServiceLocation. length); 

newServiceLocation[index] <■ inp; 

mServiceLocation - newServiceLocation; 

} else { 

this. mServiceLocation[ index] = inp; 



public void setServiceLocation(String [ ] inp){ 
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this.mServiceLocation = inp; 

public void serviceLocationFrornXML(String n){ 
setServiceLocation(-l, n); 

public ServiceOperation I ] getServiceOperation( ){ 
return mServiceOperation; 

public ServiceOperation getServiceOperation(int index) { 
if (this.mServiceOpe ration — null) 

return null; 
if (index >= this. mServiceOperation. length) 

return null; 

if (index <0 && -index > this. mServiceOperation. length) 
return null; 

if (index >- 0) return th is. mServiceOperation[ index], 

return this. mServiceOperation[this. mServiceOperation. length + index]; 

} 

public void setServiceOperation(int index ServiceOperation inp) { 
if (this.mServiceOperation *»= null) { 
if(index < 0) { 

this.mServiceOperation » new ServiceOperationdinex + 1 J 
this.mServiceOperation[0] = inp; 
} else { 

this.mServiceOperation - new ServiceOperation[ index + 1]; 
this.mServiceOperation[index] - inp; 

} 

} else if (index < 0) { 

ServiceOperation [ ] newServiceOperation - new 
ServiceOperation[this. mServiceOperation. length + 1]; 

java.lang.System.arraycopy((Object)mServiceOpe ration, 0, 
(Object)newServiceOperation, 0, this. mServiceOperation. length); 

newServiceOperation[newServiceOperation.length - 1] = inp; 

mServiceOperation - newServiceOperation; 
} else if (index >= this.mServiceOperation.length){ 

ServiceOperation [ ] newServiceOperation = new 
ServiceOperation[index + 1]; 

java.lang.System.arraycopy((Object)mServiceOperation, 0, 
(Object)newServiceOperation, 0, this.mServiceOperation. length); 

newServiceOperationf index] = inp; 

mServiceOperation - newServiceOperation; 

} else { 

th is. mServiceOperation[ index] - inp; 

} 

} 

public void setServiceOperation(ServiceOperation [ ] inp){ 
this.mServiceOperation » inp; 

} 

} 

package co m. veo.xdk. dev.schema. test.blib ; 
import com.veo .vsp.doclet.meta. Document; 
public class Service extends Document { 

public static final String DOC_TYPE - "service"; 
String mServiceName; 
String mServiceLocation; 
ServiceOperation [ ] mServiceOperation; 
String mServiceTerms; 
public Service( ){ 

super(DOC_TYPB); 
mServiceName = new String( ); 
mServiceLocation - new String( ); 

this.mServiceOperation = new ServiceOperation[0]; 
mServiceTerms = new String( ); 

} 

public Service(String doc„type){ 

super (doc type); 

mServiceName = new String( ); 
mServiceLocation « new Stringf ); 

this.mServiceOperation » new ServiceOperation[0]; 
mServiceTerms - new String( ); 
} 

static public Service initServicc (String iServiceName,String 
iServiceLocation,ServiceOperation [ ] iServiceOperation,String iService1brms){ 
Service obj ■* new Service( ); 

obj.initializeAll(iServiceName, iServiceLocation, iServiceOperation, 

iServiceTerms); 

return obj; 

} 

public void initialize All (String iServiceName,String iServiceLocation,ServiceOpe ration 
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[ ] iScrviccOpe ration, String iServiceTerms) { 

mServiceName = iServiceName; 
mScrvice Location » iScrviceLocation; 
mServiceOperation = iServiccOpcration; 
mServiceTerms - iServiceTerms; 

} 

public String getServiceName( ){ 
return mServiceName; 

} 

public String getServiceNameToXML( ){ 

if (getServiceName( ) «» null) return null; 
char [ ] c = getServiceName( ).toCharArray( ); 
StringBuffer sb = new StringBuffer( ); 
for (int x « 0; x < c. length; x++){ 
switch(c{x]){ 
case *>': 
sb.appcnd( M >"); 
break; 
case '<': 

sb.append("<"); 
break; 
case '&': 

sb.append("&"); 
break; 
case 

sb.appcnd("""); 
break; 
case 'A': 

sb.append("""); 
break; 
default: 

if (Character.isDefined(c[x])) 
sb.append(c[x]); 

} 

} 

return sb.toStringf ); 

} 

public void setServiceNa me (String inp){ 
this. mServiceName » inp; 

} 

public void serviceNameFromXML(String n){ 
setSe rviceName (n); 

public String getService Location ( ){ 
return mServiceLocation; 

} 

public String getServiceLocationToXML( ){ 

if (getService Location( ) = null) return null; 
char [ ] c = getServiceLocation( ).toCharArray( ); 
StringBuffer sb = new StringBuffer( ); 
for(int x = 0; x < c.length; x++){ 

switch(c[x]){ 

case '>': 

sb.appcnd(">"); 
break; 
case '<*: 

sb.append("<"); 

break; 
case '&*: 

sb.append("&"); 

break; 
case 

sb.appendf^""); 

break; 
case "\": 

sb .appe n d(" &quo t;") ; 

break; 
default: 

if (Character.isDefined(c[xD) 

sb.append(c[x]); 

} 

} 

return sb.toString( ); 

} 

public void setServiceLocation(String inp){ 
this. mServiceLocation » inp; 

} 

public void service LocationFromXML(String n){ 
setServiceLocation(n); 
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public ServiceOperation [ ] getServiccOperation( ){ 
return mServiceOperation; 

public ServiceOperation getServiceOperation(int index) { 
if (this.mServiceOperation =- null) 
return null; 

if (index >= this. mServiceOperation, length) 
return null; 

if (index < 0 && -index > this. mServiceOperation. length) 
return null; 

if (index >= 0) return this.mServtceOperation[index]; 

return this. mServiceOperation[this. mServiceOperation. length + index]; 

public void setServiceOperationfint index, ServiceOperation inp){ 
if (this.mServiceOperation - null) { 
if(index < 0) { 
this.mServiceOperation * new ServiceOperationfl]; 
this.mServiceOperation[0] ■» inp; 
} else { 

this.mServiceOperation = new ServiceOperation[ index +1]; 
this. mServiceOperation[ index] - inp; 

} 

} else if (index < 0) { 

ServiceOperation [ ] newServiceOperation - new 
ServiceOperation[this. mServiceOperation. length + 1]; 

java.lang.System.arraycopy((Object)mServiceOperation, 0, 
(Object)newServiceOperation, 0, this. mServiceOperation. length); 

newServiceOperationf newServiceOperation. length - 1] = inp; 

mServiceOperation - newServiceOperation; 
} else if (index >«* this.mServiceOperation.length){ 

ServiceOperation [ ] newServiceOperation - new 
ServiceOperation[index + 1]; 

java.lang.System.arraycopy((Object)mServiceOpe ration, 0, 
(Object)newServiceOperation, 0, this. mServiceOperation. length); 

newServiceOperation[index] = inp; 

mServiceOperation - newServiceOperation; 

} else { 

this. mServiceOperation[ index] ° inp; 

} 

} 

public void setServiceOperation(ServiceOperation [ ] inp){ 
this.mServiceOperation - inp; 

} 

public String getServiccTerms( ) { 
return mServiceTerms; 

} 

public String getServiceTermsToXML( ){ 

if (getServiceTerms( ) — null) return null; 
char [ ] c = getServiceTerms( ).toCharArray( ); 
StringBuffer sb - new StringBuffer( ); 
for (int x - 0; x < c.length; x++){ 
switch(c[xj){ 
case '>': 
sb.append(">"); 
break; 
case '<': 
sb.append("<"); 
break; 
case '&': 
sb .appe nd( tf & "); 
break; 

case 1 

sb .appe nd(" &quo t;"); 

break; 
case "\": 

sb.append("""); 

break; 
default: 

if (Character. isDefined(c[x])) 

sb.append(c[x]); 

} 

} 

return sb.toStringf ); 

} 

public void setServiceTerms(String inp){ 
this.mServiceTenns » inp; 

} 

public void service1ermsFromXML(String n){ 
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sctServiccTe rms(n); 

} 

} 

package com.veo.xdk.dev.schema.test.bIib; 
impo rt com .veo .vsp .docle t.meta. Docume at; 
public class ServiceOpe ration extends Document { 

public static final String DOC_TYPE - "service.ope ration"; 
String mServiceOpe ratio nName; 
String mServiceOpe ratio nLocation; 
String mServiccOpeiationlnput; 
String mServiceOperationOutput; 
public ServiceOpe ratio n( ){ 

super(DOC_TYPE); 
mServiceOpe rationName = new String( ), 
mServiceOperationLocation » new String( ); 
mServiceOperationlnput - new String ( ), 
mServiceOperationOutput - new Stringf ), 
} 

public ServiceOperation (String doc_type) { 
super (doc_type); 

mServiceOperationName - new String( ); 
mServiceOperationLocation ■ new String( ), 
mServiceOperationlnput = new Stringf ), 
mServiceOperationOutput - new String( ), 

} 

static public ServiceOperation initScrviccOpe ratio n(String 
iServiceOperationName,String iServiceOperationLocation, String iServiceOperationlnpu^String 
iServiceOperationOutput){ 

ServiceOperation obj « new ServiceOpe ratio n( ); 

obj. initialize Al 1 (iSe rviceOpe rationNa me , iServiceOperationLocation, 
iServiceOperation Input, iServiceOpe rationOutput); 

return obj; 

} 

public void initialize All (String iServiceOperationName,String 
iServiceOperationLocation,String iServiceOperationinput,String iServiceOperationOutput){ 
mServiceOperationName = iSe rviceOpe rationNa me; 
mServiceOperationLocation *» iServiceOperationLocation; 
mServiceOperationlnput - iServiceOperationlnput; 
mServiceOperationOutput = iServiceOperationOutput; 

} 

public String getServiceOperationName( ){ 

return mServiceOperationName; 

public String getServiceOperationNameToXML( ){ 

if (getServiceOperationName( ) — null) return null; 
char [ ] c = getServiceOperationNamc( ).toCharAnay( ); 
StringBuffer sb = new StringBufler( ); 
for (int x - 0; x < c. length; x++){ 
switch(c[x]){ 
case *>': 
sb.append(">"); 
break; 
case '<*: 
sb.append( M <"); 
break; 
case '&': 

sb.appendC&"); 
break; 
case **"": 

sb.append("""); 

break; 
case "\": 

sb.append("""); 

break; 
default: 

if (Character.isDefined(c{xD) 

sb,append(c[x]); 

} 

} 

return sb.toStringf ); 

} 

public void setServiceOperationName(String inp){ 
this.mServiceOperatio nName - inp; 

} 

public void serviceOperationNameFromXML(String n){ 
setServiceOperationName(n); 

} 

public String getSe rviceOpe rationLocation( ){ 
return mServiceOperationLocation; 

} 
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public String getServiceOperationLocationToXML( ){ 

if (getServiceOperationLocation( )= null) return null; 
char [ ] c = getServiceOperationLocation( ).toCharArray( ); 
StringBuffer sb = new StringBuffer( ); 
for (int x = 0; x < c. length; x++){ 
switch(c(x]){ 
case *>': 
sb.appcnd(">"); 
break; 
case '<': 
sb.appcnd("<"); 
break; 
case '&': 
sb.append( M &"); 
break; 
case 

sb.append("""); 

break; 
case "\": 

sb .appe nd(" &quo t; ") ; 

break; 
default: 

if (Character.isDefined(c[xD) 

sb.append(c[x]); 

} 

} 

return sb.toStringf ); 

} 

public void setServiceOperationLocation(String inp){ 
this. mServiceOp era tionLocation = inp; 

} 

public void serviceOperationLocationFromXML(String n){ 
setSe rviceOpe rationLoca tion(n); 

} 

public String getServiceOperationInput( ){ 
return mServiccOpcrationlnput; 

} 

public String getServiceOperationInputToXML( ){ 

if (getSe rviceOpe ratio ninput( ) == null) return null; 
char [ ] c = getServiceOperationInput( ).toChar Array ( ); 
StringBuffer sb « new StringBufferf ); 
for (int x - 0; x < clength; x++){ 
switch(c[xD{ 
case *>': 
sb.append(">"); 
break; 
case '<*: 
sb.append("&It;"); 
break; 
case 

sb.append("&'*); 
break; 
case 

sb.append("""); 

break; 
case "V*: 

sb.append("""); 

break; 
default: 

if (Character.isDefined(c[x])) 

sb.append(c[x]); 

} 

} 

return sb.toStringf ); 

} 

public void setServiceOperationInput(String inp){ 
this.mServiceOperationlnput = inp; 

} 

public void serviceOpe ratio nInputFromXML(String n){ 
setServiceOperationlnput(n); 

1 

public String getServiceOperationOutput( ){ 
return mServiceOperationOutput; 

} 

public String getServiceOperationOutputToXML( ){ 

if (getServiceOperationOutput( ) == null) return null; 
char [ ] c » getServiceOperationOutput( ).toCharArray( ); 
StringBuffer sb » new StringBuffer( ); 
for (int x - 0; x < clength; x++){ 
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switch(c(x]){ 
case *>': 

sb.append("> M ); 

break; 
case '<': 

sb.append( M <"); 

break; 
case '&': 

sb.append( w &"); 

break; 
case"'": 

sb.append(**""); 

break; 
case **\": 

sb.append(""'*); 

break; 
default: 

if (Character. isDefined(c{x])) 

sb.append(c[x]); 

} 

} 

return sb.toString( ); 

} 

public void setServiceOperationOutput(String inp){ 
this.mServiceOperationOutput - inp; 

public void serviceOperationOutputFromXML(String n){ 
se tServiceOp erationOutp ut(n) ; 

} 

} 

package co m. veo .xdk. dev.schema. test.b lib ; 
import com.veo.vsp.doclet.meta.Document; 
public class ServiceSet extends Document { 

public static final String DOC_TYPE - "service. set"; 
Service [ ] mService; 
public ServiceSet( ){ 

super(DOC_TYFE); 
this.mService » new Service[0]; 

} 

public ServiceSet(String doc_type){ 

super(doc_Jype); 

this.mService - new Service[0]; 
static public ServiceSet initServiceSet(Service [ ] iService) { 

ServiceSet obj = new ServiceSet( ); 

obj . initialize AlI(iSe rvice) ; 

return obj; 

} 

public void initialize All (Service [ ] iService) { 
mService = iService; 

public Service [ ] getService( ){ 
return mService; 

} 

public Service getService(int index) { 
if (this.mService «*= null) 

return null; 
if (index >= this.mService. length) 

return null; 

if (index <0 && -index>this.mService. length) 

return null; 
if (index >- 0) return this. mService[ index}, 
return this.mService[ this.mService. length + index]; 

} 

public void setService(int index, Service uip){ 
if (this.mService ■== null) { 
if (index < 0) { 
this.mService «= new Service [1]; 
this.mService[0] = inp; 
} else { 

this.mService - new Service[ index + 1]; 
this. mService[ index] - inp; 
} 

} else if (index < 0) { 

Service [ ] newSe rvice - new Servicef this. mService. length + 1]; 
java.lang.System.arraycopy((Object)mSe rvice, 0, (Object)newService, 

0, this.mService.length); 

newService[newSe rvice. length - 1] - inp; 
mService - newService; 
} else if (index >- this.mService.length) { 
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Service [ ] newService = new Servicefindex + It 
java.lang.System.arraycopy((Object)inService, 0, (Object) newService 



0, this. mService. length); 



} else { 



newService[ index] » inp; 
mService = newService; 

this. mService{ index] - inp; 



public void setService (Service [ ] inp) { 
this.mService - inp; 



15 

In addition to the JAVA beans set forth above, transfor- 
mation code is produced for translating from JAVA to XML 
and XML to JAVA as set forth below: 

Java to XML 

<!DOCTYPE tree SYSTEM "tree.dtd"> 
<tree source="nulT pass-through -"false"> 
<before> 

■cvardef name attribute. def"> 

<element source-" ATTRIBUTE" class="NAME" type- 

"5" position-" -2"> 
<parse> 

<data class="java.lang.String" position-" -2"/> 
</parse> 
</element> 
</vardef> 

•cvardef name="pcdata.def"> 

<element source-"PCDATA" class-"NAME" type-"4" 

position="-2"> 
<parse> 

<data class»"999" type="6" position«"-27> 
</parse> 
</element> 
</vardef> 

-cvardef name-"content.def *> 
<element source-"PCDATA"> 
<parse> 

<data class-"999" type-"6" position-"-27> 
</parse> 
</element> 
</vardef> 

-cvardef name="ServiceSet.var"> 
<element source- 

"com.veo.xdk.dev.schema.test.blib.ServiceSet" class- 

"service .set" type ="4" position-" -2"> 
<parse> 55 
<callvar name«"Service.var7> 
</parse> 
</element> 
</vardef> 

•cvardef name="PrototypeService.var"> 

<element source- 
"com.veo.xdk.dev.schema.test.blib.PrototypeService" 
class-"prototype.service" type-"4" position-"-2"> 

<parse> 65 

ccallvar name-"pcdata.def * parms-"setSource Service- 
NameToXML setGenerator service. name"/> 
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<callvar name-"pcdata.def" parms="setSource ServiceT- 
ermsToXML setGenerator service, terms' 7> 

<callvar name="pcdata.def ' parms="sctSource Scrvice- 
LocationToXML setGenerator service.location"/> 

<callvar name-"ServiceOperation.var7> 

</parse> 

</element> 

</vardef> 

<vardef name-"Service.var"> 

<element source- 
"com.veo.xdk.dev.schema.test.blib .Service" class- 
"service" type- £ 8" position="0"> 

<parse> 

<callvar name="pcdata.def" parms-"setSource Service - 
NameToXML setGenerator service. name"/> 

<callvar name="pcdata.def parms="sctSource Service- 
LocationToXML setGenerator service.location"/> 

<callvar name-"ServiceOperation.var"/> 

<callvar namc-"pcdata.def" parms-"setSource ServiceT- 
ermsToXML setGenerator service. terms"/> 

</parse> 

</element> 

</vardef> 

<vardef name="ServiceOperation.var"> 

celement source- 
"com. veo. xdk.de v.schem a. test.blib. Service Operation" 
class-" service .operation" type -"4" position-"-2"> 

<parse> 

<callvar name="pcdata.def ' parms="setSource Service - 

OperationNameToXML setGenerator 

service. operation. name"/> 
<callvar name="pcdata.def ' parms="setSource Service - 

OperationLocationToXML setGenerator 

service .operation. location"/> 
<callvar name«"pcdata.def" parms="setSource Service - 

Operationl nputToXML setGenerator 

service.operation.input"/> 
<callvar name»"pcdata.def * parms-"setSource Service - 

OperationOutputToXML setGenerator 

service .operation. output"/> 
</parse> 
</element> 
</vardef> 
</before> 
<parse> 

<callvar name-"ServiceSet.var7> 
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<callvar name="PrototypeService.var"/> 
<callvar name-"Service.var"/> 
<callvar name-"Service Operation. var"/> 
</parse> 
</tree> 
XML to Java 

<!DOCTYPE tree SYSTEM "tree.dtd"> 
<tree source-" null" pass- through-" false"> 
<before> 

<vardef name="business.var"> 
<element source-"business" 

class=" com. veo. xdk.de v.schem a. test.blib. Business" 

type«"7" setter="setBusiness"> 
<before> 

<onattribute name -"business. num be r"> 
<actions> 

<callmeth name="businessNumberFromXML"> 
<parms> 

<getattr name="business.number7> 
</parms> 
</callmeth> 
</actions> 
</onat tribute > 
</before> 
<parse> 

<callvar name-"party.name.var" parms="setPosition 30 
-17> 

<callvar name-" address .set .var"/> 
</parse> 
</element> 
</vardef> 

<vardef name="party.name.var"> 
<element source^" party. name" setter* 

"partyNameFromXML" position-"-!/' class* 

"java.lang.String"> 
<parse> 

<data class-" j ava. lang.String" position-"0"> 
</parse> 
</element> 
</vardef> 

<vardcf namc-"city.var"> 

<element source="city" setter»"cityFromXML : 

position-"-!" class«"j ava. lang .String"> 
<parse> 

<data class«"java .lang.String" position="0"> 
</parse> 
</element> 
</vardef> 

<vardef name-"internet.var"> 

<element source -"internet" setter="internetFromXML 

position*" -1" class="j ava. lang .String"> 
<parse> 

<data class«"j ava. lang.String" position-"0"/> 
</parse> 
</element> 
</vardef> 

<vardef name«"country.var"> 

<element source -"country" setter~"coun try From XML 
position-"-!" class-"j ava. lang .String"> 
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<parse> 

<data class="java.lang.String" position="0"/> 

</parse> 

</element> 

</vardef> 

<vardef name="state.var"> 

<element source="state" setter="stateFromXML 

position-" - 1 " class-" j ava .lang .S tring"> 
<parse> 

<data class="j ava. lang .String" position="0"/> 

</parse> 

</element> 

</vardef> 

<vardef name="email.var"> 

<element source="email" setter="emailFromXML 

position-" -1" class="java.lang.String"> 
<parse> 

<data class«"j ava. lang .String" position-"0'7> 

</parse> 

</element> 

</vardef> 

<vardef name="address.physical.var"> 
<element source-"address.physical" 
class- 

"co m.veo. xdk.de v.schema .test, b lib. Ad 

dressPhysical" 
type-"7" setter="setAddressPhysical"> 
<before> 
</before> 
<parse> 

<callvar name="street.var" parms="setPosition -l"/> 
<callvar name="city.var" parms="setPosition -!"/> 
<callvar name="state.var" parms="setPosition -l"/> 
<callvar name -"postcode, var" parms="setPosition -1"/ 
<callvar name-"country.var" parms-"setPosition -l"/> 
</parse> 
</element> 
</vardef> 

<vardef name»"telephone.var"> 
<element source«"telephone' 

"telephoneFromXML" position-' 

"java.lang.String"> 
<parse> 

<data class="java.lang.String" position="0"> 
</parse> 
</element> 
</vardef> 

<vardef name="person.var"> 
<element source="person" 

class-" com. veo. xdk.de v.schema. test .blib. Person" 

type-"7" setter-"setPerson"> 
<before> 

<onattribute name-"SSN"> 
<actions> 

<callmelh name-"sSNFromXML"> 
<parms> 

<getattr name-"SSN"/> 
</parms> 



setter 
'-!" class 
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</callmeth> 

</actions> 

</onattribute> 

</before> 

<parse> 

<callvar name«"party.name.var" parms-"setPosition 
-17> 

<callvar name-" address .set .var"/> 

</parse> 

</element> 

</vardef> 

<vardef name="fax.var"> 

<element source="fax" setter-" faxFromXML" position- 

"-1" class="java.lang.String"> 
<parse> 

<data class-" javs.lang.String" position="07> 

</parse> 

</element> 

</vardef> 

<vardef name="street.var"> 

<element source-"street" setter="streetFromXML" 

position-"-l" class="java.lang.String"> 
<parse> 

<data class-" java.lang.String" position="0"> 

</parse> 

</element> 

</vardef> 

<vardef name= u address.set.var"> 
<element sou rce=" ad dress .set" 

class-" co m.veo. xdk.de v.schema.test.blib.AddressSet" 

type-" 7" setter-"setAddressSet"> 
<before> 
</beforc> 
<parse> 

<callvar name-" address .physical.var"/> 

<callvar name-"telephone.var" parms="setPosition 

-r/> 

<callvar name="f3X.V3r" parms="setPosition -1"> 

<callvar name="emaiLvar" parms="setPosition -l"/> 

<callvar name-" internet .var" parms="setPosition -17> 

</parse> 

</element> 

</vardef> 

<vardef name="postcode.var"> 

<element source- "post code" setter- 
"postcodeFromXML" position-"-]." class- 
"java.lang.String"> 

<parse> 

<data class="j3V3.1ang.String" position="07> 

</parse> 

</element> 

</vardef> 

<vardef name-"market.participant.var"> 
<element source-" market.participant" 
class = 

" com. veo.xdk. dev. schema. test. blib- 
.MarketParticipant" 
type-" 7" position-"0"> 
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<before> 
</before> 
<parse> 

<callvar name="business.var7> 

<callvar name-"person.var7> 

</parse> 

</element> 

</vardef> 

</before> 

<parse> 
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'business.var7> 

'party.name.var7> 

'city.var7> 

'internet .var"/> 

country.var7> 

'state. var* V> 

'email .var"/> 

'address.physical .var"/> 

'telephone. var' V> 

'person. var7> 

'fax.var7> 

'street.var"/> 

'address .set.var"/> 

'postcode. var"/> 

'market.participant .var7> 



<callvar name-' 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
<callvar name 
</parse> 
</tree> 
Makefiles: 
# 

# this makefile was generated by bic version 0.0. May 2, 
1998 

# 
# 
# 
# 

# get the package name from the package argument 
passed to SchemaGen 

PACKAGE_NAME-com/veo/xdk/dev/schema/test/blib 
JAVA_SOURCES +=\ 

MarketParticipant.java \ 

Business Java \ 

Person.java \ 

Party.java \ 

AddressPhysical.java \ 

AddressSet.java \ 
MAKEFILE_MASTER„DIR = xxx include 

$(MAKEFILE_MASTER_DIR)/Makefile. master 
all:: $(JAVA_CLASSES) 
# 

# this makefile was generated by bic version 0.0. May 2, 
1998 

# 
# 
# 
# 

# get the package name from the package argument 
passed to SchemaGen 

PACKAGE_NAME=com/veo/xdk/dev/schema/test/blib 
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JAVA_SOURCES +«\ 

ServiceSet.java \ 

PrototypeService.java \ 

Servicejava \ 

ServiceOperation.java \ 
MAKEFILE_MASTER„DIR=xxx 
include $(M AKEFI LE_MASTER_D IR)/ 

Makefile. master 
all:: $(JAVA_CLASSES) 

Finally, the XML document instances generated at run 
time according to the model above for one example follows: 
<!DOCTYPE market.participant SYSTEM "market.par- 

ticipant.dtd"> 
<market.participant> 

<business business.number=" 1234567890"> 

<party.name>IBM</party.name> 

<address.set> 

<address.physical> 

<street>l IBM Way</street> 

<city>Palo Alto</city> 

<state>CA</state> 

<postcode>94304</postcode> 

<country>USA</country> 

</address.physical> 

<telephone>123-456-7890</telephone> 

<fax>123 456 0987</fax> 

<email>ibmec@ibm.com</email> 

</address.set> 

</business> 

</market.participant> 

<!DOCTYPE service SYSTEM "service .dtd"> 

<service.set> 

<service> 

<service.name>Order Service </service.n am e> 

<se r vice .location > www. ibm .co m/order</ 

service. location> 
<service.operation> 

<service. operation. name>Submit Order</ 

service.operation.name> 
<service. operation. location>www.ibm. com/order/ 

submit </service .location> 
< service. operation. input>urn:x- 

ibm: services: order: operations :po.dtd</ 

service. operation. input> 
<service. operation. output>urn:x- 

ibm:services:order:operations:poack.dtd</ 

service.operation.output> 
</service. opera tion> 
<service.operation> 

<service. operation. name > Track Order</ 

service.operation.name> 
<service. operation. location> www. ibm. com/order/track</ 

service. location> 
<service. operation. input>urn:x- 

ibm:services:order:operations:track.irequest.dtd</ 

service .operation.input> 
<service. operation. output>urn : x- 

ibm:services:order:operations: track. iresponse.dtd</ 

service.operation.output> 
</service.operation> 
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</service> 
</service,set> 

Using the tools along with a BID composer application, 
which provides a drag, drop and forms editing user interface, 
5 a developer is able to create a business interface definition 
and to produce a well formed, valid business interface 
definition in the form of an XML document. Thus, the 
example run time instance is a business interface definition 
for an ordering service for IBM to be used by Ingram Micro 
30 and others to order laptop computers from IBM. (There is no 
relationship between the applicant and IBM or Ingram 
Micro). Utilizing these processes, a user is able to build a 
system that allows for programming of a business interface 
using the documents defined according to the present inven- 
ts tion. 

The role of CBL and the BID processor of the present 
invention in an XML/JAVA environment can be further 
understood by the following explanation of the processing of 
a Purchase Order. 

20 Company A defines its Purchase Order document type 
using a visual programming environment that contains a 
library of CBL DTDs and modules, all defined using com- 
mon business language elements so that they contain data 
type and other interpretation information. Company A's PO 

25 might just involve minor customizations to a more generic 
"transaction document" specification that comes with the 
CBL library, or it might be built from the ground up from 
CBL modules for address, date and time, currency, etc. 
The documentation for the generic "transaction docu- 

30 ment" specification (such as the transact.dtd set out above) 
typifies the manner in which CBL specifications are built 
from modules and are interlinked with other CBL DTDs. 

A compiler takes the purchase order definition and gen- 
erates several different target forms. All of these target forms 

35 can be derived through "tree to tree" transformations of the 
original specification. The most important for this example 
are: 

(a) the XML DTD for the purchase order. 
4Q (b) a JAVA Bean that encapsulates the data structures for 
a purchase order (the JAVA classes, arguments, 
datatypes, methods, and exception structures are cre- 
ated that correspond to information in the Schema 
definition of the purchase order). 
45 (c) A "marshaling" program that converts purchase orders 
that conform to the Purchase Order DTD into a Pur- 
chase Order JAVA Bean or loads them into a database, 
or creates HTML (or an XSL style sheet) for displaying 
purchase orders in a browser. 
50 (d) An "unmarshaling" program that extracts the data 
values from Purchase Order JAVA Beans and converts 
them into an XML document that conforms to the 
Purchase Order DTD. 
Now, back to the scenario. A purchasing application 
55 generates a Purchase Order that conforms to the DTD 
specified as the service interface for a supplier who accepts 
purchase orders. 

The parser uses the purchase order DTD to decompose the 
purchase order instance into a stream of information about 
60 the elements and attribute values it contains. These "prop- 
erty sets" are then transformed into corresponding JAVA 
event objects by wrapping them with JAVA code. This 
transformation in effect treats the pieces of marked -up XML 
document as instructions in a custom programming language 
65 whose grammar is defined by the DTD. These JAVA events 
can now be processed by the marshaling applications gen- 
erated by the compiler to "load" JAVA Bean data structures. 
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Turning the XML document into a set of events for JAVA 
applications to process, is unlike the normal model of 
parsing in which the parser output is maintained as an 
internal data structure and processing does not begin until 
parsing completes. The event based processing, in response 5 
to the BID definitions, is the key to enabling the much richer 
functionality of the processor because it allows concurrent 
document application processing to begin as soon as the first 
event is emitted. 

JAVA programs that "listen for" events of various types 
are generated from the Schema definition of those events. 
These listeners are programs created to carry out the busi- 
ness logic associated with the XML definitions in the CBL; 
for example, associated with an "address" element may be 
code that validates the postal code by checking a database. 
These listeners "subscribe" to events by registering with the 
document router, which directs the relevant events to all the 
subscribers who are interested in them. 

This publish and subscribe architecture means that new 
listener programs can be added without knowledge by or 2Q 
impact on existing ones. Each listener has a queue into 
which the router directs its events, which enables multiple 
listeners can handle events in parallel at their own pace. 

For the example purchase order here, there might be 
listeners for: 

the purchase order, which would connect it to an order 

entry program, 
product descriptions, which might check inventory, 
address information, which could check Fed Ex or other 

service for delivery availability, 30 
buyer information, which could check order history (for 
creditworthiness, or to offer a promotion, or similar 
processing based on knowing who the customer is). 
Complex listeners can be created as configurations of 
primitive ones (e.g., a purchase order listener may contain 35 
and invoke these listeners here, or they may be invoked on 
their own). 

FIG. 11 illustrates the market maker node in the network 
of FIG. 1. The market maker node includes the basic 
structures of the system of FIG. 3, including a network 40 
interface 1101, a document parser 1102, a document to host 
and host to document translator 1103, and a front end 1104, 
referred to as a router in this example. The market maker 
module 1105 in this example includes a set of business 
interface definitions, or other identifiers sufiBcient to support 45 
the market maker function, for participants in the market, a 
CBL repository, and a compiler all serving the participants 
in the market. The router 1104 includes a participant registry 
and document filters which respond to the events generated 
at the output of the translator and by the parser to route 50 
incoming documents according to the participant registry 
and according to the element and attribute filters amongst 
the listeners to the XML event generators. Thus, certain 
participants in the market may register to receive documents 
that meet prespecified parameters. For example, input docu- 55 
ments according to a particular DTD, and including an 
attribute such as numbers of products to be purchased 
greater than a threshold, or such as a maximum price of a 
document request to be purchased, can be used to filter 
documents at the router 1104. Only such documents as 60 
match the information registered in the participant registry at 
the router 1104 are then passed on to the registered partici- 
pant. 

The router 1104 may also serve local host services 1105 
and 1106, and as such act as a participant in the market as 65 
well as the market maker. Typically, documents that are 
received by the router 1104 are traversed to determine the 



destinations to which such documents should be routed, 
there again passed back through the translator 1103, if 
necessary, and out the network interface 1101 to the respec- 
tive destinations. 

The market maker is a server that binds together a set of 
internal and external business services to create a virtual 
enterprise or trading community. The server parses incoming 
documents and invokes the appropriate services by, for 
example, handing off a request for product data to a catalog 
server or forwarding a purchase order to an ERP system. The 
server also handles translation tasks, mapping the informa- 
tion from a company's XML documents onto document 
formats used by trading partners and into data formats 
required by its legacy systems. 

With respect to the service definition above, when a 
company submits a purchase order, the XML parser in the 
server uses the purchase order DTD to transform the pur- 
chase order instance into a stream of information events. 
These events are then routed to any application that is 
programmed to handle events of a given type; in some cases, 
the information is forwarded over the Internet to a different 
business entirely. In the purchase order example, several 
applications may act on information coming from the parser: 

An order entry program processes the purchase order as a 
complete message; 

An ERP system checks inventory for the products 
described in the purchase order; 

A customer database verifies or updates the customer's 
address; 

A shipping company uses the address information to 

schedule a delivery 
A bank uses the credit card information to authorize the 

transaction. 

Trading partners need only agree on the structure, content, 
and sequencing of the business documents they exchange, 
not on the details of APIs. How a document is processed and 
what actions result is strictly up to the business providing the 
service. This elevates integration from the system level to 
the business level. It enables a business to present a clean 
and stable interface to its business partners despite changes 
in its internal technology implementation, organization, or 
processes. 

FIGS. 12, 13 and 14 illustrate processes executed at a 
market maker node in the system of FIG. 11. In FIG. 12, an 
input document is received at the network interface from an 
originating participant node (step 1200). The document is 
parsed (step 1201). The document is translated to the format 
of the host, for example XML to JAVA (step 1202). The host 
formatted events and objects are then passed to the router 
service (step 1203). The services registered to accept the 
document according to the document type and content of the 
document are identified (step 1204). The document or a 
portion of the document is passed to the identified services 
(step 1205). As service is performed in response to the 
document content (step 1206). The output data of the service 
is produced (step 1207). The output is converted to the 
document format, for example from a JAVA format to an 
XML format (step 1208). Finally, the output document is 
sent to a participant node (step 1209). 

The registration service is one such function which is 
managed by the router. Thus, a market participant document 
is accepted at the network interface as shown in FIG. 13 
(step 1300). The market participant document is stored in the 
business interface definition repository (step 1301) for the 
market maker node. In addition, the document is parsed 
(step 1302). The parsed document is translated into the 



3/18/05, EAST Version: 2.0.1.4 



US 6,226,675 Bl 
79 80 

format of the host (step 1303). Next, the document is passed JAVA documents which have the same status as the docu- 

to the router service (step 1304). The router service includes ment type definitions received in the XML format are 

a listener which identifies the registration service as the produced. The JAVA beans are passed to the document 

destination of the document according to the document type router 1503. The document router 1503 receives the JAVA 

and content (step 1305). The document or elements of the 5 beans and passes the received class to the appropriate 

document are passed to the registration service (step 1306). document service using a registry program, for example 

In the registration service, the needed service specifications using the event listener architecture described above. The 

are retrieved according to the business interface definition document service 1504 which receives the document in the 

(step 1307). If the service specifications are gathered, at step form of JAVA beans from the router 1503 acts as the 

1308, the router service filters are set according to the 10 interface to the enterprise solution software. This includes a 

business interface definition and the service specifications registry service 1510 by which listeners to XML events are 

(step 1309). Registration acknowledgment data is produced coupled with the incoming data streams, and a service 

(1310). The registration acknowledgment data is converted manager 1511 to manage the routing of the incoming 

to a document format (step 1311). Finally, the acknowledg- documents to the appropriate services. The document ser- 

ment document is sent to the participant node indicating to 15 vice manager 1511 provides for administration of the reg- 

the participant that is successfully registered with the market istry service and for maintaining document consistency and 

maker (step 1312). the like. 

The process at step 1307 of gathering needed service The document service communicates with the back end 

specifications is illustrated for one example in FIG. 14. This system using any proprietary API, or using such more 

process begins by locating a service business interface 20 common forms as the CORBA/COM interface or other 

definition supported by the market participant (step 1400). architectures. 

The service definition is retrieved, for example by an E-mail FIG. 16 provides a heuristic diagram of the market maker 
transaction or web access to repository node (step 1401). and market participant structures according to the present 
The service specification is stored in the BID repository invention. Thus, the electronic commerce market according 
(step 1402). The service business interface definition docu- 25 to the present invention can be logically organized as set 
ment is parsed (step 1403). The parsed document is trans- forth in FIG. 16. At the top of the organization, a market 
lated into the format of the host (step 1404). Host objects are maker node 1600 is established. The market maker node 
passed to the router service (step 1405). The registration includes resources that establish a marketplace 1601. Such 
service is identified according to the document type and resources include a market registry service and the like, 
content (step 1406). Finally, the information in the service 30 Businesses 1602 register in the marketplace 1601 by pub- 
business interface definition document is passed to the Ashing a business interface definition. The business interface 
registration service (step 1407) for use according to the definition defines the services 1603 for commercial trans- 
process of FIG. 13. actions in which the businesses will participate. The trans- 

FIG. 15 illustrates the processor, components and actions 160* and services 1603 use documents 1605 to 
sequence of processing of incoming data at market maker 35 define the inputs and outputs, and outline the commercial 
node according to the present invention. The market maker relationship between participants in the transaction. The 
node includes a communication agent 1500 at the network documents have content 1606 which carries the particulars 
interface. The communication agent is coupled with an of each transaction. The manner in which the content is 
XML parser 1501 which supplies events to an XML pro- processed by the participants in the market, and by the 
cessor 1502. The XML processor supplies events to a 40 market maker is completely independent of the document 
document router. The document router feeds a document based electronic commerce network which is established 
service 1504 that provides an interface for supplying the according to the present invention. Overall, a robust, 
received documents to the enterprise solution software 1505 scalable, intuitive structure is presented for enabling elec- 
in the host system. The communication agent 1500 is an tr onic commerce on communication networks is provided. 
Internet interface which includes appropriate protocol stacks 45 Thus* the present invention in an exemplary system 
supporting such protocols as HTTP, SMTP, FTP, or other provides a platform based on the XML processor and uses 
protocols. Thus, the incoming data could come in an XML XML documents as the interface between loosely coupled 
syntax, an ASCII data syntax or other syntax as suits a business systems. The documents are transferred between 
particular communication channel. All the documents businesses and processed by participant nodes before enter- 
received in non-XML syntaxes are translated into XML and 50 ing the company business system. Thus the platform enables 
passed the XM4L parser. A translation table 1506 is used to electronic commerce applications between businesses where 
support the translation from non-XML form into XML form. each business system operates using different internal com- 

The converted documents are supplied to the parser 1501. merce platforms, processes and semantics, by specifying a 

The XML parser parses the received XML document common set of business documents and forms, 

according to the document type definition which matches it. 55 According to the present invention, virtual enterprises are 

If an error is found, then the parser sends the document back created by interconnecting business systems and service, are 

to the communication agent 1500. A business interface primarily defined in terms of the documents (XML-encoded) 

definition compiler BIDC 1507 acts as a compiler for th at businesses accept and generate: 

business interface definition data. The DTD file for the XML "if you send me a request for a catalog, I will send you a 

parser, JAVA beans corresponding to the DTD file, and 60 catalog: 

translation rules for translating DTD files to JAVA beans are "if you send me a purchase order and I can accept it, I will 

created by compiling the BID data. An XML instance is send you an invoice". 

translated to JAVA instance by referring to these tools. Thus The foregoing description of a preferred embodiment of 

the BID compiler 1507 stores the DTD documents 1508 and the invention has been presented for purposes of illustration 

produces JAVA documents which correspond 1509. The 65 and description. It is not intended to be exhaustive or to limit 

XML documents are passed to the processor 1502 which the invention to the precise forms disclosed. Obviously, 

translates them into the JAVA format. In a preferred system, many modifications and variations will be apparent to prac- 
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titioners skilled in this art. It is intended that the scope of the 
invention be defined by the following claims and their 
equivalents. 

What is claimed is: 

1. A method for executing transactions among nodes in a 5 
network including a plurality of nodes which execute pro- 
cesses involved in the transactions, comprising: 

storing a machine-readable specification of an interface 
for a transaction, the specification including a definition 
of an input document, and a definition of an output 10 
document, the definitions of the input and output docu- 
ments comprising respective descriptions of sets of 
storage units and logical structures for the sets of 
storage units; 

receiving data comprising a document through a commu- 15 

nication network; 
parsing the document according to the specification to 

identify an input document; 
providing at least a portion of the input document in a 2 o 

machine-readable format to a transaction process 

which produces an output; 
forming, based on the specification, an output document 

comprising the output according to the definition of an 

output document; and 25 
transmitting the output document on the communication 

network. 

2. The method of claim 1, including: 

accessing a specification of a complementary interface 
provided for another node in the network for the 
transaction, the accessed specification including a defi- 
nition of an input document for the complementary 
interface, and a definition of an output document for the 
complementary interface; and 

establishing the stored specification of the interface by 
including at least part of the definition of the output 
document of the complementary interface in the defi- 
nition of the input document of the interface in the 
stored specification. 

3. The method of claim 2, including: 
finding the complementary interface in the network. 

4. The method of claim 2, wherein the establishing the 
stored specification includes accessing elements of the 
machine -readable specification from a repository, the reposi- 45 
tory storing a library of logical structures, schematic maps 
for logic structures, and definitions of documents compris- 
ing logic structures used to build interface descriptions. 

5. The method of claim 2, including: 

establishing the stored specification of the interface by 50 
including at least part of the definition of the input 
document of the complementary interface in the defi- 
nition of the output document of the interface in the 
stored specification. 

6. The method of claim 1, including providing access to 55 
the specification through the communication network to 
other nodes in the network. 

7. The method of claim 1, including sending the specifi- 
cation of the interface to another node in the network, at 
which access to the specification is provided for other nodes 60 
in the network. 

8. The method of claim 1, wherein the machine-readable 
specification includes a document compliant with a defini- 
tion of an interface document including logical structures for 
storing an identifier of a particular transaction, and at least 65 
one of definitions and references to definitions of input and 
output documents for the particular transaction. 
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9. The method of claim 1, wherein the machine-readable 
specification includes a document compliant with a defini- 
tion of an interface document including logical structures for 
storing an identifier of the interface, and for storing at least 
one of specifications and references to specifications of a set 
of one or more transactions supported by the interface. 

10. The method of claim 9, wherein the machine-readable 
specification includes a reference to a specification of a 
particular transaction, and the specification of the particular 
transaction includes a document including logical structures 
for storing at least one of definitions and references to 
definitions of input and output documents for the particular 
transaction. 

11. The method of claim 1, wherein the storage units 
comprise parsed data. 

12. The method of claim 11, wherein the parsed data in at 
least one of the input and output documents comprises: 

character data encoding text characters in the one of the 

input and output documents, and 
markup data identifying sets of storage units according to 

the logical structure of the one of the input and output 

documents. 

13. The method of claim 12, wherein at least one of the 
sets of storage units encodes a plurality of text characters 
providing a natural language word. 

14. The method of claim 11, wherein the specification 
includes interpretation information for at least one of the sets 
of storage units identified by the logical structure of at least 
one of the input and output documents, encoding respective 
definitions for sets of parsed characters. 

15. The method of claim 11, wherein the storage units 
comprise unparsed data. 

16. The method of claim 1, wherein the transaction 
process has a variant transaction processing architecture, 
and including translating at least of portion of the input 
document into a format readable according to the variant 
transaction processing architecture of the transaction pro- 
cess. 

17. The method of claim 16, wherein the translating 
includes producing programming objects including vari- 
ables and methods according to the variant transaction 
processing architecture of the transaction process. 

18. The method of claim 16, wherein the variant trans- 
action processing architecture of the transaction process 
includes a process compliant with an interface description 
language. 

19. The method of claim 1, wherein the definitions of the 
input and output documents comprise document type defi- 
nitions compliant with a standard Extensible Markup Lan- 
guage XML. 

20. The method of claim 1, including providing a reposi- 
tory of document types for use in a plurality of transactions, 
and wherein the definition of one of the input and output 
documents includes a reference to a document type in the 
repository. 

21. The method of claim 20, wherein the repository of 
document types includes a document type for identifying 
participant processes in the network. 

22. The method of claim 20, including providing a reposi- 
tory of interpretation information for logical structures, 
including interpretation information identifying parameters 
of transactions. 

23. The method of claim 1, wherein the transaction 
process has variant transaction processing architecture, and 
including: 

accessing a specification of a complementary interface, 
the accessed specification including a definition of an 
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input document for the complementary interface, and a 
definition of an output document for the complemen- 
tary interface; 

establishing the stored specification of the interface by 
including the definition of the output document of the 5 
complementary interface as the definition of the input 
document of the interface in the stored specification; 
and 

compiling in response to the definitions of the input and 
output documents, data structures corresponding to the 10 
sets of storage units and logical structures of the input 
and output documents compliant with the transaction 
processing architecture of the transaction process, 
instructions executable by the system to translate the 
input document to the corresponding data structures, 35 
and instructions executable by the system to translate 
output of the transaction process into a form compliant 
with the definition of the output document. 

24. The method of claim 23, including: 

20 

establishing the stored specification of the interface by 
including the definition of the input document of the 
complementary interface as the definition of the output 
document of the interface in the stored specification. 

25. The method of claim 1, wherein the transaction 

25 

process has a variant transaction processing architecture, 
and wherein the establishing the stored specification 
includes accessing elements of the machine-readable speci- 
fication from a repository, the repository storing a library of 
logical structures, schematic maps for logical structures, and 
definitions of documents comprising logical structures used 
to build interface descriptions; and including 

compiling in response to the definitions of the input and 
output documents, data structures corresponding to the 
sets of storage units and logical structures of the input 35 
and output documents compliant with the transaction 
processing architecture of the transaction process, 
instructions executable by the system to translate the 
input document to the corresponding data structures, 
and instructions executable by the system to translate 4Q 
output of the transaction process into a form compliant 
with the definition of the output document. 

26. Apparatus for managing transactions among nodes in 
a network including a plurality of nodes which execute 
processes involved in the transactions, comprising: 45 

a network interface; 

memory storing data and programs of instructions, includ- 
ing a machine-readable specification of an interface for 
a transaction, the specification including a definition of 
an input document, and a definition of an output 50 
document, the definitions of the input and output docu- 
ments comprising respective descriptions of sets of 
storage units and logical structures for the sets of 
storage units; 

a data processor coupled to the memory and the network 55 
interface which executes the programs of instructions; 
wherein the programs of instructions include 
logic to receive data comprising a document through a 

network interface; 
logic to parse the document according to the specifi- 60 

cation to identify an input document; 
logic to provide at least a portion of the input document 

in a machine-readable format to a transaction process 

which produces an output; 
logic to form, based on the specification, an output 65 

document comprising the output according to the 

definition of an output document; and 
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logic to transmit the output document on the network 
interface. 

27. The apparatus of claim 26, including: 

logic to access a specification of a complementary 
interface, the accessed specification including a defi- 
nition of an input document for the complementary 
interface, and a definition of an output document for the 
complementary interface; and 

logic to establish the stored specification of the interface 
by including the definition of the output document of 
the complementary interface as the definition of the 
input document of the interface in the stored specifi- 
cation. 

28. The apparatus of claim 27, wherein the logic to 
establish the stored specification includes logic to access 
elements of the machine-readable specification from a 
repository, the repository storing a library of logical 
structures, schematic maps for logic structures, and defini- 
tions of documents comprising logic structures used to build 
interface descriptions. 

29. The apparatus of claim 27, including: 

logic to establish the stored specification of the interface 
by including the definition of the input document of the 
complementary interface as the definition of the output 
document of the interface in the stored specification. 

30. The apparatus of claim 26, including logic to provide 
access to the specification through the network interface to 
other nodes in the network. 

31. The apparatus of claim 26, including logic to send the 
specification of the interface to another node in the network, 
at which access to the specification is provided for other 
nodes in the network. 

32. The apparatus of claim 26, wherein the machine- 
readable specification includes a document compliant with a 
definition of an interface document including logical struc- 
tures for storing an identifier of a particular transaction, and 
at least one of definitions and references to definitions of 
input and output documents for the particular transaction. 

33. The apparatus of claim 26, wherein the machine- 
readable specification includes a document compliant with a 
definition of an interface document including logical struc- 
tures for storing an identifier of the interface, and for storing 
at least one of specifications and references to specifications 
of a set of one or more transactions supported by the 
interface. 

34. The apparatus of claim 33, wherein the machine- 
readable specification includes a reference to a specification 
of a particular transaction, and the specification of the 
particular transaction includes a document including logical 
structures for storing at least one of definitions and refer- 
ences to definitions of input and output documents for the 
particular transaction. 

35. The apparatus of claim 26, wherein the storage units 
comprise parsed data. 

36. The apparatus of claim 35, wherein the parsed data in 
at least one of the input and output documents comprises: 

character data encoding text characters in the one of the 

input and output documents, and 
markup data identifying sets of storage units according to 

the logical structure of the one of the input and output 

documents. 

37. The apparatus of claim 36, wherein at least one of the 
sets of storage units encodes a plurality of text characters 
providing a natural language word. 

38. The apparatus of claim 35, wherein the specification 
includes interpretation information for at least one of the sets 
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of storage units identified by the logical structure of at least 
one of the input and output documents, encoding respective 
definitions for sets of parsed characters. 

39. The apparatus of claim 35, wherein the storage units 
comprise unparsed data. 5 

40. The apparatus of claim 26, wherein the transaction 
process has variant transaction processing architecture, and 
including logic to translate at least of portion of the input 
document into a format readable according to the variant 
transaction processing architecture of the transaction pro- 30 
cess. 

41. The apparatus of claim 40, wherein the logic to 
translate includes logic to produce programming objects 
including variables and methods according to the variant 
transaction processing architecture of the transaction pro- 15 
cess. 

42. The apparatus of claim 40, wherein the variant trans- 
action processing architecture of the transaction process 
includes a process compliant with an interface description 
language. 20 

43. The apparatus of claim 26, wherein the definitions of 
the input and output documents comprise document type 
definitions compliant with a standard Extensible Markup 
Language XML. 

44. The apparatus of claim 26, including memory acces- 25 
sible by the processor storing a repository of document types 
for use in a plurality of transactions, and wherein the 
definition of one of the input and output documents includes 

a reference to a document type in the repository, 

45. The apparatus of claim 44, wherein the repository of 30 
document types includes a document type for identifying 
participant processes in the network. 

46. The apparatus of claim 44, including providing a 
repository of interpretation information for logical 
structures, including interpretation information identifying 35 
parameters of transactions. 

47. The apparatus of claim 26, wherein the transaction 
process has variant transaction processing architecture, and 
including: 

logic to access a specification of a complementary 40 
interface, the accessed specification including a defi- 
nition of an input document for the complementary 
interface, and a definition of an output document for the 
complementary interface; 



,675 Bl 

86 

logic to establish the stored specification of the interface 
by including the definition of the output document of 
the complementary interface as the definition of the 
input document of the interface in the stored specifi- 
cation; and 

logic to compile in response to the definitions of the input 
and output documents, data structures corresponding to 
the sets of storage units and logical structures of the 
input and output documents compliant with the trans- 
action processing architecture of the transaction 
process, to compile instructions executable by the 
system to translate the input document to the corre- 
sponding data structures, and to compile instructions 
executable by the system to translate output of the 
transaction process into a form compliant with the 
definition of the output document. 

48. The apparatus of claim 47, including: 

logic to establish the stored specification of the interface 
by including the definition of the input document of the 
complementary interface as the definition of the output 
document of the interface in the stored specification. 

49. The apparatus of claim 26, wherein the transaction 
process has a variant transaction processing architecture, 
and including logic to establish the stored specification by 
accessing elements of the machine -readable specification 
from a repository, the repository storing a library of logical 
structures, schematic maps for logical structures, and defi- 
nitions of documents comprising logical structures used to 
build interface descriptions; and including 

logic to compile in response to the definitions of the input 
and output documents, data structures corresponding to 
the sets of storage units and logical structures of the 
input and output documents compliant with the trans- 
action processing architecture of the transaction 
process, to compile instructions executable by the 
system to translate the input document to the corre- 
sponding data structures, and to compile instructions 
executable by the system to translate output of the 
transaction process into a form compliant with the 
definition of the output document. 
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